Technique for implementing interstitial web advertising through use of an Ad Descriptor file

ABSTRACT

A technique for implementing in a networked client-server environment, e.g., the Internet, network-distributed advertising in which advertisements are downloaded, from an advertising server to a browser executing at a client computer, in a manner transparent to a user situated at the browser, and subsequently displayed, by that browser and on an interstitial basis, in response to a click-stream generated by the user to move from one web page to the next. Specifically, an HTML advertising tag is embedded into a referring web page. This tag contains two components. One component effectively downloads, from an distribution web server and to an extent necessary, and then persistently instantiates an agent at the client browser. This agent “politely” and transparently downloads advertising files (media and where necessary player files), originating from an ad management system residing on a third-party advertising web server, for a given advertisement into browser cache and subsequently plays those media files through the browser on an interstitial basis and in response to a user click-stream. The other component is a reference, in terms of a web address, of the advertising management system. This latter reference totally “decouples” advertising content from a web page such that a web page, rather than embedding actual advertising content within the page itself, merely includes an advertising tag that refers, via a URL, to a specific ad management system rather than to a particular advertisement or its content. The ad management system selects the given advertisement that is to be downloaded, rather than having that selection or its content being embedded in the web content page.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application is a continuation-in-part of our co-pending U.S.patent application entitled “LOCALLY-SUMMONED NETWORK-DISTRIBUTEDCONFIRMED INFORMATIONAL PRESENTATIONS”, filed May 15, 1998 and assignedSer. No. 09/080,165; the latter application is incorporated by referenceherein.

BACKGROUND OF THE DISCLOSURE

[0002] 1. Field of the Invention

[0003] The invention relates to a technique, specifically apparatus andaccompanying methods, for implementing in a networked client-serverenvironment, such as the Internet, network-distributed advertising inwhich an advertisement is downloaded, from an advertising server to aweb browser executing at a client computer, in a manner transparent to auser situated at the browser, and subsequently displayed, by thatbrowser and on an interstitial basis, in response to a click-streamgenerated by the user to move from one web page to the next.

[0004] 2. Description of the Prior Art

[0005] Currently, Internet usage, and particularly that of the WorldWide Web (henceforth referred to as simply the “web”), is growingexplosively, particularly as the number of web sites and users that haveaccess to the Internet continue to rapidly and to a great extent,exponentially, expand.

[0006] In essence, after establishing a suitable network connection tothe Internet, a user at a client computer can easily employ a graphicalweb browser, such as the Internet Explorer (“IE”) browser presentlyavailable from Microsoft Corporation of Redmond, Washington, to connectto a web site and then download a desired web page by simply supplying aspecific address (known as a URL or uniform resource locator) of thatpage to the browser. The URL identifies both an address of the site, interms of its Internet domain name, and a page of information at thatsite, in terms of its corresponding file name. Each web site stores atleast one, and often times substantially more pages all arranged in apre-defined hierarchy, generally beginning, at its root, with aso-called “home page”. Each such page is written in HTML (hypertextmarkup language) form. A page, in this context, refers to contentaccessed via a single URL, including, e.g., text, graphics and otherinformation specified in the code for that particular page. Once a usersupplies an URL of interest, the browser operated by that user sends anappropriate command, using a TCP/IP protocol (transmission controlprotocol/internet protocol), to a remote HTTP (hypertext transportprotocol) server, located at the web site and which stores that page, toaccess and download a corresponding file for that page. In response, theserver then sends, using the TCP/IP protocol, a stored file containingHTML code that constitutes that page back to the browser. As the filethat constitutes the page itself is received by the browser, the browserinterprets and executes the HTML code in that file to properly assembleand render the page on, e.g., a monitor to a user situated at the clientcomputer. Such a page may itself contain HTML commands that referenceother files, residing on the same or different web sites, which, whenthese commands are appropriately interpreted and executed by thebrowser, result in those files being downloaded and their resultingcontent properly assembled by the browser into the rendered page. Onceall the content associated with the page is rendered, the user can thenposition his(her) mouse cursor on a suitable hypertext link, button orother suitable user input field (whichever here implements a “hotlink”)displayed on that page and then, through, e.g., a mouse “click”,effectively download a file for and render another desired page insuccession until the user has finished his(her) visit to that site, atwhich point, the user can transition through a hotlink to a page atanother site, and so forth. A hotlink specifies a complete web addressof an associated page, including a domain name of its hosting web siteat which that page is situated. Consequently, by simply and successivelypositioning and “clicking” his(her) mouse at an appropriate hotlink foreach one of a number of desired web pages, the user can readily retrievean HTML file for each desired page in succession from its correspondingweb site and render that page, and, by doing so, essentiallyeffortlessly jump from site to site, regardless of where those sites arephysically located.

[0007] Ever since their introduction several years ago, HTML andaccompanying browser software, now including, e.g., attendantprogramming languages such as Java and JavaScript languages (“Java” is aregistered trademark of Sun Microsystems in Mountain View, Calif.;“JavaScript” is a trademark of Netscape Communications in Mountain View,Calif.), have undergone rather rapid and continual evolution. A majorpurpose of which has been and continues to be to provide web pageauthors with an ability to render increasingly rich content throughtheir pages and, as a result, heighten a “user experience” for thoseusers who visit these pages. Consequently, web pages are no longerlimited to relatively simple textual displays—as occurred with earlyversions of HTML and browser software, but can now encompass evenfull-motion multimedia presentations and interactive games that userather sophisticated graphics.

[0008] The simplicity of browsing the web coupled with the relativelow-cost of accessing the Internet, and the relative ease through whicha web site can be established are collectively fueling unparalleledgrowth and diffusion of the Internet itself, web sites and the Internetuser community throughout the world. In that regard, by establishing websites, merchants, vendors and other information providers have anunparalleled opportunity, basically unheard of as little as 5-10 yearsago, to reach enormous numbers of potential consumers—regardless ofwhere these consumers reside—at costs far less than previously thoughtpossible. Moreover, given the staggering amount and wide diversity ofinformation currently available on the web, web browsing is becoming sopopular a past-time for sufficient numbers of individuals that browsingis beginning to divert significant viewership away from traditionalforms of mass entertainment, such as television and cable. While suchdiversion is relatively small at present, it is likely to rapidly grow.Moreover, given the ease and convenience with which users, situated attheir personal computers and with basically nothing more complicatedthan a few mouse clicks, can effectively interact with remote web sites,electronic commerce, through which goods and services are orderedthrough the Internet without ever visiting a physical store, is rapidlyemerging as a significant sales medium. This medium is likely tosignificantly challenge and possibly, over a relatively short time, mayeven alter traditional forms of retailing.

[0009] Given the wide and ever-growing reach of the web as a source ofconsumer information and the increasing consumer acceptance ofelectronic commerce, advertisers have clearly recognized the immensepotential of the web as an effective medium for disseminatingadvertisements to a consuming public.

[0010] Unfortunately, conventional web-based advertising, for variouspractical reasons—some being technical in nature and others relating toa nature of traditional web advertisements themselves, has generallyyielded unsatisfactory results and thus has usually been shunned by mostlarge advertisers. In that regard, several approaches exist in the artfor implementing web based advertisements. However, all suffer seriouslimitations of one form or another that have sharply restricted theirdesirability and use.

[0011] Currently, a predominant format, referred to as a “banner”, for aweb advertisement takes the form of a rectangular graphical displaysituated, typically at a fixed location, in a rendered web page. Abanner, which can be static or animated, can be situated anywhere withina rendered web page but most often is situated at a top or bottom, oralong a vertical edge of that page. A banner, depending on its size, canextend across an entire page width or length, and usually contains, in agraphical eye-catching form, a name of a product or service beingadvertised. Increasingly, a banner for a given product or serviceimplements a hotlink to enable a consumer to “click-through” the banner(i.e., generate a mouse click on the banner) in order to transition, viahis browser, to a web site maintained by a corresponding advertiser and,from that site, fetch a web page to provide additional informationregarding that product or service. Hence, the consumer could easilyobtain more information by a click-through; while an advertiser,monitoring counts of such click-throughs that occur in a given period oftime, could gain feedback on the effectiveness of the correspondingbanner.

[0012] A banner is generally produced by properly embedding specificHTML code for that banner within the HTML coding for a given web page inwhich the banner is to appear. A client browser, as it interprets andsequentially executes the HTML code for a fetched page, will, in turn,compile and execute the embedded code for the banner and hence displaythe banner, as part of a rendered page and at a specified locationthereon.

[0013] In implementing a banner, whether static or even animated, itsHTML coding generally involved downloading an appropriate file, for thatbanner, to a client browser. The file may be stored on the same serverthat stores the HTML file for the page, or accessed from a remoteserver. The file may contain a graphic itself, such as in a GIF (graphicinterchange format) file, or a Java applet which, once interpreted andexecuted by the browser, generates and renders a desired animatedgraphic. This file, whether it be a graphic or applet, requires time todownload and must be downloaded and assembled by the browser on the pageprior to that page being fully rendered. The download time for thatfile, particularly as it increases in size, clearly, a priori, lengthensa time interval during which that page would completely download,thereby extending the time to fully render the page, including thebanner, after a user transitioned to that page. Channel bandwidth to aclient computer (e.g., personal computer —PC), such as that providedthrough a modem connection, is often rather limited. Consequently, ifthe file size for the banner were relatively large—as would certainly bethe case for relatively “rich” content, e.g., audio or video content,the delay in downloading such a file over such a limited bandwidthconnection could be excessive, and consequently highly frustrating tothe user. Hence, a user would likely wait a considerable amount of timebefore all the page components for multimedia content are fullydownloaded to permit that page to be rendered. Such delay, ifencountered during a page transition, can be rather frustrating to auser, even to the point at which the user, just to end his(her) waiting,will prematurely terminate the download and transition to another page.Therefore, in an effort to preserve an appropriate “editorialexperience” for a user, content suppliers sharply limit the file size,of such banners to be rendered on their pages, in order to minimize pagedownload and hence latency times.

[0014] Unfortunately, such restricted file sizes effectively limit therichness of the content of a banner to a rather simplisticadvertisement—even with animation. Thus, banners often failed, asadvertisers soon recognized by relatively low click-through counts, toattract sufficient viewer attention to justify their use and expense.

[0015] In an effort to overcome the content limitation associated withbanners, the art teaches the use of a different advertising modality:so-called “interstitial” advertisements. See, e.g., U.S. Pat. No.5,305,195 (issued to A. J. Murphy on Apr. 19, 1994—hereinafter the“Murphy” patent) which discloses the concept of using interstitialadvertisements though not in the context of web advertising. Asdescribed in the Murphy patent, pre-stored advertisements are displayedat specific intervals on each one of a group of networked ATM (automatedtransaction machines) terminals. In particular, the advertisements aredownloaded, either directly or via a server, from a remote computer andlocally stored on each such terminal and subsequently displayed on thatterminal while it waits for a response, from a remote mainframetransaction server, to a transaction initiated at that terminal.

[0016] Generally speaking and with specific reference to webadvertising, interstitial ads are displayed in an interval of time thatoccurs after a user has clicked on a hot-link displayed by a browser toretrieve a desired web page but before that browser has startedrendering that page. Such an interval, commonly referred to as an“interstitial”, arises for the simple reason that a browser requirestime, once a user clicks on a hotlink for a new page, to fetch a file(s)from a remote web server(s) for that particular page and then fullyassemble and render that page. The length of an interstitial interval,which is quite variable, is governed by a variety of factors, including,e.g., a number of files required to fully render the new page and thesize of each such file, and network and server congestion and attendantdelays occurring when the user activated the hotlink.

[0017] Interstitial web advertising is taught in, e.g., U.S. Pat. Nos.5,737,619 and 5,572,643 (both of which issued to D. H. Judson but onApr. 7, 1998 and Nov. 5, 1996, respectively—hereinafter the “Judson”patents). The Judson patents disclose the concept of embedding anadvertisement, as an information object, in a web page file in such amanner that the object will remain hidden and not displayed when thefile is executed to render the page. Rather than being displayed, theinformation object is locally cached by the browser during execution ofthe code for that page. Then, during a transition initiated by useractivation of a hotlink to move from that page to a next successivepage, i.e., during an interstitial, the browser accesses theadvertisement from local cache and displays it until such time as thatnext successive page is downloaded and rendered. See also, publishedInternational patent application WO 97/07656 (to E. Barkat et al andpublished on Mar. 6, 1997) which teaches the concept of “polite”downloading. Here, a browser, on a local computer (e.g., a client PC)downloads, from an remote advertising system server and ostensibly as abackground process, file(s) for a web advertisement only during thoseintervals when bandwidth utilization of a communication channel (link)connected to the browser is less than a pre-established threshold. Such“polite” downloading is intended to minimally interfere with othercommunication applications, then executing on the client PC, which willutilize the link. The browser displays the downloaded ad(s) to the useronly after the user has not interacted, as detected by a conventionalscreen saver process, with his(her) PC for a predefined period of time,such as by neither moving a mouse nor depressing a key on a keyboardduring that period. The server selects those advertisements for downloadto the client PC based on a user-ID and preference information of theuser, who is then situated at that PC, and configuration information ofthat PC, which, when a connection is established between the client PCand the server, the client PC uploads to the server. Though the filesassociated with an interstitial advertisement can be large, these filesare advantageously fetched by a client browser during those intervalswhen otherwise the browser would be idle and hence bandwidth utilizationof its network connection would be relatively low. Such “idle times”would occur, in the absence of processing an interstitial ad, after thebrowser has fully rendered a web page and a user is viewing the page buthas not yet clicked on a hotlink to transition to another page. Duringsuch an idle time, the browser would simply wait for further user input.

[0018] By reducing, if not eliminating, problems, inherent in bannersand engendered by download latency, interstitial web advertisements, byemploying idle time downloading and local caching, provide a theoreticalpromise of conveying very rich media content with a pleasing “userexperience”. However, interstitial advertisements, as conventionallyimplemented, have serious practical deficiencies which have severelylimited their use.

[0019] Conventional interstitial, as well as other forms of current, webadvertisements—here not unlike banners—rely on embedding HTML ad code,as, e.g., a separate non-displayable object, within HTML coding for aweb page. Unfortunately, this approach, inherent in that taught by theJudson patents, can be inflexible and expensive for an advertiser toimplement and particularly later should that advertiser, for whateverreason, seek to modify his(her) ad content. In particular and presently,ad coding is manually inserted into each and every content web page thatis to carry advertising. Consequently, insertion of increasinglysophisticated embedded advertising, such as multi-media or video oraudio, in existing web site content requires a large investment in termsof human resources, time and cost as web sites, particularly largesites, increase a number of content pages available for advertising. Inthat regard, where a banner usually required insertion of, e.g., asingle line of HTML code, content rich advertisements, such as those nowimplemented by parameterized embedded Java advertising applets, oftenconsist of an entire page of coding and hence require far more extensiveand increasingly labor-intensive and costly insertions. Moreover, overtime, advertisers do change their ads—such as by replacing one ad with atotally new version. However, once HTML ad coding is embedded within anumber of web pages, it can be quite impractical and rather costly foran advertiser to access each and every page in which his(her) ad codinghas been inserted and then manually change the ad coding, as desired.The impracticality and attendant cost compound if these pages are copiedto other web sites and hence diffuse through the Internet.

[0020] Given these deficiencies, the art teaches a concept ofimplementing web advertising through using so-called “push” technology.See, e.g., U.S. Pat. No. 5,740,549 (issued to J. P. Reilly et al on Apr.14, 1998—hereinafter the “Reilly et al” patent). In essence and asdescribed in the Reilly et al patent, a client PC, through execution ofa “push” application program (called “administration manager”),establishes a network connection with an information server, i.e., a“push” web server, typically during off-hours, such as in the lateevening or early morning, or at a predefined interval (e.g., every fourhours). The information server then downloads, i.e., “pushes”, to theadministration manager, content files, such as for advertisements and/orother predefined information, that are to be played to the user sometimelater. The administration manager, i.e., the “push” application, inturn, stores all the “pushed” content files into a local database(referred to as the “information database”) on a local hard disk and, inresponse to instructions received from the information server, deletesthose previously “pushed” content files which have already beendisplayed. The administration manager also maintains a user profile,which specifies user preferences as to the specific advertising and/orother information (s)he wants to receive, in the information database.As such, through each connection, the information server, by selectingcontent from its database relative to preferences specified in the userprofile, attempts to “push” fresh content to the client PC that islikely to be of interest to the user but without duplicating that whichwas already displayed. Stored “pushed” content is later displayed, usinga data viewer, either on user demand or during those times when the useris not interacting with the system, here too detected by a conventionalscreen saver procedure.

[0021] While push technology reduces download latency, by shiftingdownloads to occur at off-hours, this technology also suffers seriousdrawbacks which have greatly restricted its practical acceptance.

[0022] In particular, to access “pushed” content, a user must initiallydownload and install to his(her) client PC a separate,platform-specific, software application program, as well as subsequentupdates to that program as new push capabilities are released by themanufacturer of the program. Unfortunately, these application programscan often extend to tens of megabytes in length. Since typical Internetusers establish modem connections to their Internet service provider,these users will find that downloading these relatively large programfiles, even in compressed form, will consume an inordinate amount oftime and is generally impractical while (s)he is actively using his(her)client PC. Consequently, these users are constrained to purchasing, atsome cost, an off-the-shelf version of the application program ordownloading that program, typically at no cost for the program itself,at off-hours, when network congestion is relatively light. Furthermore,while some efforts are underway in the art to automatically “push” andinstall incremental software updates to a client PC, thus eliminating aneed for a user to manually do so, the user still faces the burdenassociated with the initial download and installation of the “push”application program.

[0023] In addition, “push” application programs continue to increase insize, often considerably, as they provide added capabilities to a user.Downloading and then regularly updating a push application will reduce,sometimes considerably, the amount of disk space available to the useron his(her) client PC. Furthermore, “push” applications rely onperiodically “pushing” large quantities of media content from a pushserver to the client PC and storing that content on the hard disk ofthat PC pending subsequent display. This content, depending on itsvolume, can consume inordinate amounts of hard disk space. Furthermore,advertisers have discovered, not surprisingly, that relatively few PCusers will undertake any affirmative action, such as by downloading andinstalling an application program—almost regardless of its size, toreceive advertisements and other such information.

[0024] Faced with these practical, and rather acute, deficienciesinhering in web advertising conventionally provided on either aninterstitial or “push” basis, web advertisers have apparently relegatedtheir efforts to displaying their advertisements on a banner-likeapproach, through real-time downloading and rendering of advertisingHTML files. Here, the advertising files are sited on remote web servers,rather than being embedded within given web page HTML files, withappropriate HTML tags, which reference the ad files, being embedded intothe web page files themselves. Such a tag specifies when and where,within the page, an advertisement is to appear.

[0025] To surmount the latency problems inherent in such banner-likeadvertisements, various proprietary media formats have appeared in theart. These formats employ increasingly sophisticated data compression,sometimes in conjunction with video and/or audio streaming. Rather thanwaiting for a media file to fully download prior to its being rendered,streaming permits content in a “streamed” media file to be presented inreal-time to the user as that content arrives at his(her) clientbrowser. While this approach clearly provides enhanced richness incontent over that obtainable through a conventional banner and thus canheighten a “user experience”, it nevertheless relies, to its detriment,on a continuous real-time network connection existing to a remote webserver.

[0026] Unfortunately, any network or server congestion which stops thedownload, even if temporary, can suspend, i.e., freeze, or totally haltthe “streamed” media presentation to the user prior to its completion.This interruption, if noticeable and sufficiently long, will likelyfrustrate the user and degrade the “user experience”.

[0027] In spite of these drawbacks, particularly with respect tointerstitial advertisements and push technology, and apparently for lackof a better alternative, most web advertising currently in use employsreal-time streaming of graphic files with their content being renderedby the browser.

[0028] Web advertisements, like other forms of mass advertising, dogenerate revenue, often in the form of an on-going stream of payments tothe host of the ads, in this case web site owners. Accurate useraccounting is essential to ensure that an advertiser is not over- orunder-charged given an extent to which an ad is actually disseminated.Hence, these payments are often tied to a function of the number of webusers whom the ad reached. But with web advertisements, accuratelyascertaining that number has been difficult and problematic at best,and, given a basic technique employed to do so, manifestly error-prone,thereby causing unreliable user counts and erroneous ad charges.

[0029] In particular and as conventionally employed, delivery of a webadvertisement, such as, e.g., a streamed ad, is logged as a “userimpression” at a web server at an instant an advertising file(s), e.g.,a streamed file, is served, rather than after the browser has completelyrendered the advertisement to the user. Unfortunately, serving these adfiles does not guarantee that these files will be ultimately andcompletely rendered by a client browser to a user. Consequently, webserver generated “user impression” counts can be grossly understated.For example, if a user navigates to a new content page after anadvertisement has started playing but before that advertisementcompletes and, by doing so, prematurely terminated the advertisement, afull impression is nevertheless logged—erroneously—since thatadvertisement was completely served. Additional errors arise if a proxyserver is situated between multiple client PCs situated on an intranetor a local area network (LAN) and a web advertisement server situated onthe Internet (or other insecure public network). In this case, a requestfrom one of the client PCs for the advertisement files will be routed tothe proxy server, which, in turn, will direct that request onward to theadvertisement web server. The latter, in response to the request, willserve one complete copy of the advertisement files to the proxy server.The resulting fetched advertisement files will be locally cached in theproxy server and, from there, provided to the requesting client PC.Should any of the other client PCs request the same files, the proxyserver will provide these files, totally unbeknownst to the web server,from its local cache rather than directing a request from that other PCback to the web server. Hence, the web server will be totally obliviousto each additional instance in which the proxy server accessed the adfiles from its local cache and disseminated the advertisement to anyclient PC other than that which first requested the ad. Inasmuch as someintranets situated behind a proxy server(s) can be rather extensive withtens or hundreds of thousands of individual client PCs, server-baseduser impression accounting based on copies delivered by a web servermay, owing to the presence of proxy servers, be inordinately low andresult in significant under-charges to the advertiser. As of yet, nosolution apparently exists in the art that can provide accurate countsof “user impressions” of web advertisements.

[0030] Other conventional approaches aimed at reducing latency timesassociated with downloading content files through relatively slow speedcommunication links, e.g., modem connections, have involved developmentand use of new facilities within various programming languages. Theseapproaches, most notably involving the Java and JavaScript programminglanguages, while helpful, still cause inefficient use of available linkbandwidth and still constrain the size of the content files. Theselimitations arise from premature terminations of preloaded fileswhenever a user transitions to a new web page. Specifically, with theseapproaches, if a user activates a hotlink to transition to a new webpage while an ad file is being downloaded but before the downloading hascompleted, then the downloading simply stops. The downloading will needto be re-started, but from the beginning of the file, the next time thatparticular ad file is requested. Hence, the time and bandwidth that hasthen been expended in downloading part of that ad file is completelywasted. In practice, many users tend to quickly navigate through aseries of web pages until they reach a desired destination.Consequently, advertisers are constrained to again minimize content filesizes and hence “richness” of their advertisements in an effort todecrease a number of premature terminations per unit time and in doingso reduce latency caused by downloading duplicate sections of the samead file. Therefore, these approaches have generally proven to be whollyunsatisfactory.

[0031] In view of the fundamental drawbacks associated with various webbased advertising techniques known in the art, interstitial webadvertising appears to hold the most promise of all these techniques.Yet, the limitations inherent in conventional implementations ofconventional interstitial advertising have effectively prevented thisform of web advertising from effectively fulfilling its promise.Moreover, the deficiencies inherent in all known web advertisingtechniques have, to a significant extent, collectively inhibited the useof web advertising in general.

[0032] Thus, a pressing need exists in the art for a new web-basedinterstitial advertising technique which does not suffer frominfirmities associated with such interstitial advertising techniquesknown in the art.

[0033] In that regard, this new technique should preferably not embedadvertising HTML files within a web page. If this could be accomplished,then advantageously such a technique would likely provide considerableeconomies to advertisers in saved labor, time and cost in terms of bothinserting advertisements into web page files, and later changing any ofthose advertisements. In addition, such a new technique shouldpreferably function in a manner that is substantially, if not totally,transparent to a user and which neither inconveniences nor burdens thatuser. In particular, this new technique should preferably not require auser to download and install on his(her) PC a separate applicationprogram, let alone any update to it, specifically to receive webadvertising, or perform any affirmative act, other than normal webbrowsing, to receive such advertising. Furthermore, this new techniqueshould preferably be platform independent and, by doing so, operate withsubstantially any web browser on substantially any PC. Also, this newtechnique, when in use, should preferably not consume excessive harddisk space on a client PC. Moreover, to provide a pleasing “userexperience”, this new technique should render an ad fully and withoutany interruptions that might otherwise result from network and/or servercongestion. Lastly, this new technique should provide proper accountingto an advertiser by accurately and validly ascertaining user impressionsof fully rendered advertisements.

[0034] We believe that if such a new web-based interstitial advertisingtechnique could be provided, then this technique, which should be botheffective and desirable, may well achieve broad support and use byadvertisers and acceptance by web users; hence, substantially expandingthe use of web-based advertising in general.

SUMMARY OF THE INVENTION

[0035] Advantageously, our present inventive technique satisfies thisneed by overcoming the deficiencies associated with conventionalweb-based interstitial advertising techniques.

[0036] Our present invention accomplishes this, in accordance with ourbroad inventive teachings, by: completely “decoupling” advertisingcontent from a web content page (also hereinafter referred to as a“referring” page); “politely” downloading advertising files, through abrowser executing at a client computer, into browser caches (e.g.,browser disk and RAM cache) at that computer and in a manner that istransparent to a user situated at the browser; and interstitiallydisplaying advertisements through the browser in response to a userclick-stream associated with normal user navigation across different webpages.

[0037] Specifically, our technique relies on embedding an HTML tag(which, where necessary, to distinguish this tag from other HTML tags,will be also referred to hereinafter as an “advertising tag”) into areferring page. This tag contains two components. One componenteffectively downloads, from an distribution HTTP (web) server and to anextent necessary, and then persistently instantiates an agent,implemented as a “light-weight” Java applet, at the client browser. Thisagent then “politely” and transparently downloads advertising files(media, and, where necessary, player files), originating from an admanagement system residing on a third-party advertising HTTP (web)server, for a given advertisement into browser disk cache (also in thecase of media files into the browser RAM cache) and subsequently playsthose media files through the browser on an interstitial basis and inresponse to a user click-stream. The other component is a reference, interms of a web address, of the advertising management system from whichthe advertising files are to be downloaded. This latter referencetotally “decouples” advertising content from a web page such that a webpage, rather than embedding actual advertising content within the pageitself—as conventionally occurs, merely includes an advertising tag thatrefers, via a URL, to a specific ad management system rather than to aparticular advertisement or its content. The ad management systemselects the given advertisement that is to be downloaded, rather thanhaving that selection or its content being embedded in the web contentpage.

[0038] Advantageously, the agent operates independently, in the clientbrowser, of the content in any referring web page. Once loaded andstarted, the agent executes in parallel, with standard browserfunctionality, continually and transparently requesting and downloadingadvertisements to browser cache residing in a client computer (e.g.,personal computer—PC) and interstitially playing those advertisements.

[0039] In particular, once the agent is started, the agent politely andtransparently downloads, through the client browser and to the browsercache, both media and player files, originating from the advertisementmanagement server, for an advertisement that are needed to fully playcontent in that advertisement. The agent also monitors a click-streamgenerated by a user who then operates the browser. In response to auser-initiated action, e.g., a mouse click, which instructs the clientbrowser to transition to a next successive content web page and whichsignifies a start of an interstitial interval, the agent, if all themedia and player files are then resident on the client hard disk, playsthe media files, through the browser and during that interstitialinterval, directly from the browser cache. Advertisements areinterstitially played typically in the order in which they weredownloaded to the client browser. Interstitial play from browser cacheadvantageously permits previously cached content rich advertisements tobe played through the browser without adversely affecting communicationlink bandwidth then available to the client browser. Thus, the fullavailable link bandwidth can be used, while an advertisement is beingplayed, to download a next successive content web page.

[0040] Employing a user click-stream to trigger play of cachedadvertisements frees the user, for receiving advertising, of any needeither to undertake any affirmative action, other than normal webbrowsing, or to learn any new procedure; thus, advantageously imposingno added burden on the user.

[0041] Advantageously, the agent “politely” downloads advertisementmedia and player files, originating from the advertising server, to thebrowser cache, during what otherwise would be browser idle times, i.e.,while a web page is being displayed to a user and the browser is waitingfor user input. Caching advertisement files in this fashionadvantageously circumvents variable latency and erratic (e.g.,intermittent or suspended) play that frequently occurs with conventionalstreamed and static media delivered over the web.

[0042] At the start of an interstitial interval, the agent determineswhether all the media and player files required to play a givenadvertisement (typically that having its so-called AdDescriptor filesituated in a head of a play queue) then reside on the disk of theclient PC or, with respect to media files, are resident in browser RAMcache. If so, the agent then accesses these files from the disk to“play” that advertisement. Since all the media and player files are thenlocally resident, the advertisement, from a user's perspective, isimmediately rendered from the client hard disk or browser RAM cache withessentially no downloading delay, thus providing a highly pleasing “userexperience” with rich multi-media content approaching that obtainablethrough current CD-ROM based delivery. Thereafter, the agent returnscontrol to the browser to permit the browser, if a next successive webpage has been downloaded, assembled and ready to be rendered, to renderthat particular page to the user. If, however, an advertisement isprematurely terminated by a user, that advertisement (in terms of itsAdDescriptor file) will remain in a play queue (with its media andplayer files remaining on the client hard disk or, in the case of mediafiles, in browser RAM cache) and will be re-played from its beginning atthe start of a next successive interstitial interval. Furthermore, ifdownload of the media and player files for an advertisement were to beinterrupted by a user click-stream, i.e., start of interstitialinterval, the agent suspends further downloading until after the ensuinginterstitial interval terminates. To conserve communication linkbandwidth, the agent then resumes downloading of these files at a pointit was suspended, rather than, as conventionally occurs, totallyre-starting the download.

[0043] In accordance with our specific inventive teachings, the agentcontains two applets: a Transition Sensor applet and an “AdController”applet. Only the Transition Sensor applet is itself associated with anycontent page. Though the AdController applet, once started, executesunder the browser, it is not under the control of the browser itself.

[0044] The advertising tag is itself embedded in a content web page andreferences a JavaScript file. The advertising tag also encapsulates areference, i.e., a URL to a specific ad management server, typicallysited on a third party advertising server, containing specific media,that collectively constitutes web advertisements, and accompanyingplayer files. The file, when executed, downloads and implements, throughdynamic writing of applet tags, the Transition Sensor applet. Thisparticular applet remains visually transparent to a user who displays,with his(her) browser, the HTML coding for that page. In particular, theadvertising tag references a JavaScript file (which contains a “script”)stored on a distribution server. When the JavaScript file is downloadedand the script it contains is then executed by the browser, the scriptdynamically writes a predefined number and combination of applet tags,i.e., which collectively form the Transition Sensor applet, into theretrieved web page content in lieu of the advertising tag. Subsequentexecution of these tags, by the client browser, invokes the TransitionSensor applet.

[0045] In particular, when executed, the Transition Sensor appletinstantiates an Applet Registry, which is used for inter-appletcommunication. Thereafter, the Transition Sensor applet determineswhether the AdController applet has been downloaded to the browser diskcache or whether an updated version of this particular applet resides onthe distribution server. If an updated version of this applet exists onthe distribution server relative to that previously downloaded to thebrowser disk cache or if this applet has not been download at all ontothis cache, the Transition Sensor applet loads the AdController appletfrom the distribution server into the browser disk cache. The TransitionSensor applet then instantiates the AdController applet. Once thisoccurs, the Transition Sensor applet then establishes appropriateentries in the Applet Registry for itself and the AdController applet.

[0046] The Transition Sensor applet then passes the URL of the admanagement system, as specified in the advertising tag, to theAdController applet in order for the latter applet to request deliveryof an advertisement, specifically an associated AdDescriptor file,originating from that system. The system then selects the advertisementto be delivered and, via the third party advertising server, so informsthe AdController applet by returning the requested AdDescriptor file.For a given advertisement, this particular file, which is textual innature, contains a manifest, i.e., a list, of: file names andcorresponding web addresses of all media files that constitute contentfor that advertisement and all player files necessary to play all themedia files; an order in which the various media files are to be played;and various configuration and other parameters need to configure andoperate the operation of each player in order for it to properly play acorresponding media file(s). The AdController then “politely” downloads,typically via the advertising distribution server, the associated mediaand player files, as specified in the AdDescriptor file—and to theextent they do not already reside on the hard disk of the client PC. Asnoted above, the Transition Sensor applet also monitors a click-streamproduced by the current user to detect a user-initiated page transitionand hence the start of an interstitial interval.

[0047] Advantageously, the AdDescriptor file implements a dataabstraction that totally separates the media and player files from thereferring web page thus assuring that the advertisement content itselfremains completely independent of the content web page that invoked itspresentation. This abstraction permits our technique to provide a highlyeffective, generalized and very flexible mechanism for delivering richweb advertisements, particularly those that require complex sets ofmedia files and players. Through use of this abstraction, our techniqueis able to handle present and future media formats, regardless of theirrequirements, including proprietary streaming and other content deliverytechnologies that rely on Java applets as a delivery mechanism—alltransparently to the user. Moreover, since the AdDescriptor file canspecify media and player files for different browsers, operating systemsand computing platforms then in use, our technique can readily functionwith a wide variety of different computing and browsing platforms.

[0048] The Transition Sensor and AdController applets are eachimplemented through appropriate Java classes and collectively persist,through storage in the browser disk cache, across different contentpages within a site, across different web sites, and across successivebrowser sessions. Once either of these applets is completely downloaded,providing it is not subsequently flushed from the browser disk cache asthe user navigates across web sites on the web, the files for thatapplet will be loaded from that cache, rather than being downloaded fromthe distribution server, the next time that applet is required, e.g.,when the user next navigates, either during a current browser session ora subsequent session, to any content page that contains an advertisingtag.

[0049] Whenever the client browser encounters a next successive pagecontaining an advertising tag, then the browser will first andautomatically inquire with the distribution server to ensure thatexecutable code for the Transition Sensor applet, if previouslydownloaded into the browser disk cache, has not been superseded by anupdated version. If such an updated version then exists, the browserwill collectively download updated files from the distribution serverand replace, to the extent necessary, each Transition Sensor applet fileresiding in the browser disk cache with its updated version.Alternatively, if the Transition Sensor applet has not been previouslydownloaded into the browser disk cache, then the browser will downloadall the necessary files for the Transition Sensor applet from thedistribution server into that cache. The Transition Sensor applet, onceexecuting, will load, through the browser, the AdController applet. Todo so, the browser will, if necessary, obtain an updated version, fromthe distribution server, in the same manner as it did for the TransitionSensor. As a result, any corrections or enhancements made to the agent(specifically the Transition Sensor and/or the AdController applets)since the agent was last downloaded to the client browser will beautomatically and transparently, from a user perspective, distributed tothat browser and downloaded into the browser disk cache the next timethe browser encounters a web page containing an advertising tag. Byoperating in this fashion, the user is totally and advantageouslyrelieved of any need to: both initially load and install an applicationprogram to obtain advertising and/or later update that program.

[0050] Furthermore, the agent advantageously persists and functionstransparently in background, independent and transparent to usernavigation across pages on a common web site and across web sites. Theagent effectively implements a background process which runs in parallelwith and is transparent to normal HTML and HTTP operations implementedby the client browser.

[0051] Moreover, in sharp contrast to conventional server-basedaccounting of web advertisements, our inventive technique provideshighly accurate client-side accounting of each user impression. Each logentry, produced by the AdController applet, specifies a successfulpresentation of a complete advertisement at a client browser. This entrymay include a source of the ad content, i.e., in terms of the URL of theassociated ad management system, a title of the advertisement and theURL of the referring web page. Other client-side information can bemeasured and included in each entry, such as: an amount of time duringwhich the advertisement was rendered by the browser (presumably duringwhich the user dwelled on the advertisement); as well as anidentification, in terms of a URL, of a content web page to which theuser next navigated (particularly if the user reached that page througha hotlink displayed in the advertisement). Subsequently, theAdController applet uploads the log entries to the advertising server.These entries will be collectively processed, as needed, to permitshared ad revenues from web-based advertisers to be properly allocatedamong different web page content providers.

[0052] Advantageously, our inventive technique, by totally decouplingreferring web page content from its corresponding advertising content,easily permits an advertiser to change or update any of itsadvertisements by just modifying, as needed, appropriate media andAdDescriptor files that reside in the third-party advertising managementsystem. Since a referring web page merely incorporates an advertisingtag totally devoid of advertising content, no changes whatsoever need tobe made to that page. Hence, use of our inventive techniquesubstantially reduces the burden, time and cost associated withmaintaining and updating web-based advertising over that conventionallyrequired.

[0053] As a feature, our inventive technique advantageously implements,in conjunction with its persistent agent approach, multi-threadedpipelining. By processing each different advertisement as a differentthread, each one of a sequence of different processing operations can beperformed, effectively on a pipe-lined parallel basis, on differentsequentially occurring advertisements, thereby enhancing a rate(increasing throughput) at which advertisements can be queued forplayback. In addition, through such pipe-lining, logging of a fullypresented advertisement can occur as a last operation in a pipeline andessentially in parallel either: with presentation of cachedadvertisement having its AdDescriptor file situated in the play queueimmediately behind that for the just presented advertisement, or withdownloading and caching of a next successive advertisement.

BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The teachings of the present invention can be readily understoodby considering the following detailed description in conjunction withthe accompanying drawings, in which:

[0055]FIG. 1A depicts the correct alignment of the drawing sheets forFIGS. 1B and 1C;

[0056]FIGS. 1B and 1C collectively depict a high-level block diagram ofan illustrative client-server distributed processing environment,implemented through the Internet, which embodies the teachings of ourpresent invention, along with, as pertinent to the invention, basicinter-computer actions that occur in that environment and associatedclient processing operations;

[0057]FIG. 1D depicts the correct alignment of the drawing sheets forFIGS. 1E and 1F;

[0058]FIGS. 1E and 1F collectively depict the same environment as shownin FIGS. 1B and 1C but showing an detailed version of agentdownload/instantiate/execute operations 50 shown in the latter figures;

[0059]FIG. 2 depicts the correct alignment of the drawing sheets forFIGS. 2A and 2B;

[0060]FIGS. 2A and 2B collectively depict generalized web page HTML code35, specifically inclusion of advertising tag 40, which transparentlyinvokes our invention, and changes which our invention dynamically makesto that code, specifically substitution of Transition Sensor applet 210for tag 40 to yield page 35′, in order to download and render webadvertisements;

[0061]FIG. 3 depicts a high-level block diagram of client PC 5 shown inFIGS. 1B and 1C, and 1E and 1F;

[0062]FIG. 4 depicts a simplified high-level block diagram ofapplication programs 400 resident within client PC 5 shown in FIG. 3;

[0063]FIG. 5 depicts a high-level block diagram of AdController agent420 shown in FIG. 4, which implements our present invention;

[0064]FIG. 6 depicts the correct alignment of the drawing sheets forFIGS. 6A and 6B;

[0065]FIGS. 6A and 6B collectively depict a high-level flowchart ofprocessing operations 600 performed by AdController agent 420 shown inFIG. 5;

[0066]FIG. 7 depicts a high-level block diagram of basic processingthreads that implement AdController applet 424 which, as shown in FIG.4, forms part of AdController agent 420;

[0067]FIG. 8 depicts a high-level flowchart of processing operations 800performed by AdController applet 424 shown in FIG. 7;

[0068]FIG. 9 depicts the correct alignment of the drawing sheets forFIGS. 9A and 9B;

[0069]FIGS. 9A and 9B collectively depict a flowchart of processingoperations 900 performed by AdController applet 424, shown in FIG. 7,specifically for processing an advertisement;

[0070]FIG. 10 depicts inter-applet events that occur within AdControlleragent 420 during execution of Transition Sensor applet 422;

[0071]FIG. 11 depicts a high-level block diagram of basic processingthreads that implement Transition Sensor applet 422 which, as shown inFIG. 4, forms part of AdController agent 420;

[0072]FIG. 12 depicts a high-level flowchart of processing operations1200 performed by Transition Sensor applet 422 shown in FIG. 11;

[0073]FIG. 13 depicts a high-level block diagram of Ad Loader process1300 which can be used to provide advertiser control over variousfunctions, for advertisement play and logging, implemented byAdController applet 424;

[0074]FIG. 14 depicts a high-level block diagram of Ad Pipeline 545 thatis implemented by and forms part of AdController applet 424 shown inFIG. 4;

[0075]FIG. 15 depicts a high-level block diagram of Ad Producer process1500 that is executed by Ad Pipeline 545 shown in FIG. 14;

[0076]FIG. 16 depicts a high-level block diagram of Ad Location process1600 that is also executed by Ad Pipeline 545 shown in FIG. 14;

[0077]FIG. 17 depicts a high-level block diagram of Ad Downloaderprocess 1700 that is also executed by Ad Pipeline 545 shown in FIG. 14;

[0078]FIG. 18 depicts a flowchart of stop method 1800 invoked byTransition Sensor applet 422 shown in FIG. 4;

[0079]FIG. 19 depicts a flowchart of start method 1900 invoked byTransition Sensor applet 422 shown in FIG. 4; and

[0080]FIG. 20 depicts contents of actual illustrative AdDescriptor file2000 for use in interstitially rendering a PointCast type Javaadvertisement through our present invention.

[0081] To facilitate understanding, identical reference numerals havebeen used, where possible, to designate identical elements that arecommon to the figures.

DETAILED DESCRIPTION

[0082] After considering the following description, those skilled in theart will clearly realize that the teachings of our present invention canbe utilized in any networked client-server environment in whichadvertising or other information is to be presented to a user duringinterstitial intervals, i.e., during a transition between successivelydisplayed web pages. Such an environment can encompass the Internet oran intranet, or any client-server environment in which a client browser(regardless of whether that browser executes on a dedicated clientcomputer or not) is used to access and download web pages or, moregenerally speaking, files through a network communication channel (link)from a server (again regardless of whether that server executes on adedicated computer or not). In that regard, the server can be a separatesoftware application which executes on any computer in the networkedenvironment, even if that computer is itself a client to another serverin the network.

[0083] For purposes of simplicity and to facilitate readerunderstanding, we will discuss our present invention in the illustrativecontext of use in rendering interstitial web-based advertisements to aclient personal computer (PC) connected to the Internet, wherespecifically a client browser executing in the PC is used to downloadand render web pages from a remote networked Internet accessible webserver. Clearly, after considering the ensuing description, anyoneskilled in the art will readily appreciate how the teachings of ourinvention can be easily incorporated into any client-server or othersimilar distributed processing environment in which a client canencompass not only a specific computer connected to a network but asoftware process that possesses network connectivity to another suchprocess and requests information from and, in response, obtainsinformation supplied by the latter.

[0084] We will first present an overview of our invention, particularlyin the context of its use with an Internet web browser in a client PC,followed by describing each basic component of its implementation.

[0085] A. Overview

[0086] A general deployment of our invention in an Internet environmentis collectively shown in FIGS. 1B and 1C, with a detailed view of aportion of the inter-processor agent download/instantiation operations50 shown in these figures being depicted in FIGS. 1E and 1F. The correctalignment of the drawing sheets for FIGS. 1B and 1C, and 1E and 1F isshown in FIGS. 1A and 1D, respectively. FIGS. 2A and 2B, for which thecorrect alignment of the drawing sheets for these figures is shown inFIG. 2, collectively depicts generalized web page HTML code whichtransparently invokes our invention, and changes which our inventiondynamically makes to that code in order to download and render webadvertisements. For a understanding, the reader should simultaneouslyrefer to FIGS. 1B and 1C, 1E and 1F, and 2A and 2B throughput thefollowing discussion.

[0087] As shown, client PC 5, upon which client browser 7 executes, isconnected through communication link 9 to Internet 10. Browser 7 is aconventional web browser, such as Internet Explorer or NetscapeNavigator commercially available from Microsoft Corporation or NetscapeCorporation, respectively. Preferably, for reasons that will shortlybecome clear, that browser should preferably support dynamic writing ofapplet tags. Though, for ease of illustrating inter-computer actions, wedepicted Internet 10 as having portions 10 _(A) and 10 _(B), we willcollectively refer to both portions as simply Internet 10. Web server13, connected, via link 11, to Internet 10 represents any web HTTP(hypertext transfer protocol) server. This server, in response to arequest to fetch a specific file from web browser 7, downloads thatfile, using conventional TCP/IP protocols (transmission controlprotocols/internet protocols), through the Internet to browser 7.Browser 7 will, in turn, render that file typically on a monitor to auser situated at the client PC.

[0088] Advertising distribution HTTP server (also referred to as “agent”server) 15 is connected, via communications link 17, to Internet 10 andstores files that collectively implement a predefined agent,specifically, a light weight Java applet. This agent (referred to hereinas the “AdController” agent) transparently pre-loads itself, as well asmedia rich advertising content, into a local hard disk cache associatedwith the browser (“browser disk cache”) on client PC 5. Server 15downloads the AdController agent in a manner to be described below, toclient browser 7. This agent, once instantiated and started, thentransparently and politely downloads (actually pre-loads) advertisementsinto the browser disk cache, and subsequently plays each of thoseadvertisements, on an interstitial basis, in response to a click streamgenerated by the user as (s)he navigates, through use of browser 7,between successive web pages. Such hard disk caching advantageouslycircumvents variable latency and erratic play associated withconventional streamed and static media delivered over the Internet. Theagent enables rich advertising to be presented in a highly-controlledfashion, resulting in user experiences approaching that of CD-ROM.

[0089] Third-party ad HTTP server 20, connected to Internet 10 via,e.g., communications links 18 and 23, hosts ad management system 25. Inessence and as discussed in detail below, this system, in response to arequest originating from the AdController agent executing in browser 7,selects a given advertisement and then downloads, in a “polite” mannercontrolled by the agent, media and player files that form thatadvertisement to the agent for storage in the browser disk cache.Inasmuch as Java applets are currently restricted under constraintsinherent in the Java programming language itself to retrieving filesfrom an identical Internet host that served the applet itself, therequest for an advertisement to system 25 as well as resulting media andplayer files served by system 25 are routed through agent server 15 as aproxy server.

[0090] Advantageously, our inventive technique completely “decouples”advertising content from a web content page (also hereinafter referredto as a “referring” page). This, in turn, permits our technique torender media-rich advertisements without requiring inclusion of anyadvertising content into a referring web page. This “decoupling” iseffectuated through inclusion of an HTML tag into a content web page,which when the latter is downloaded, interpreted and executed by thebrowser, effectively loads and instantiates the agent and then retrievesadvertisement files from an ad management system specified in the tag.Thus, advertising files (both media and player files) can be maintainedtotally independently of their referring web page(s), withadvantageously any changes made to the former having no effect on HTMLcoding contained in the latter.

[0091] In particular, HTML tag 40 (which, where necessary, todistinguish this tag from other HTML tags, will be also referred tohereinafter as an “advertising tag”) is embedded by a contentprovider(s) into HTML code that constitutes each referring web page,e.g., here page 35. Generally, the position of this tag relative toexisting HTML code (shown as HTML code portions 35 _(A) and 35 _(B) inFIGS. 2A and 2B) for this page is not critical. Advantageously, veryrarely, if ever at all, do any changes need to be made to these codeportions to accommodate the tag. As shown and as reproduced in Table 1below, this tag, which typically consumes one line in a web page,implements a script. TABLE 1 ADVERTISING TAG <SCRIPTSRC=http://unicast.com/loadad.js> AdServer=“http://AdManagement system”</SCRIPT>

[0092] One portion of the advertising tag(“SRC=http://unicast.com/loadad.js”), when executed by the browser,downloads a JavaScript file (named “loadad.js”) from the agent server.This file, in turn, is then interpreted and executed, as a script, bythe browser. The effect of executing this script, as symbolized by block200 shown in FIGS. 2A and 2B, is to substitute applet tags, dynamicallywritten by the script, into the referring web page in lieu ofadvertising tag 40 so as to form a modified web page, here referringcontent page 35′, residing in the browser disk cache. The script, byinvoking a feature associated with dynamic writing, completely hidesthese tags from view should the user then display HTML source code forpage 35′ with his browser. This, in turn, hinders the user, to a certaindegree, from readily ascertaining the source of the agent and admanagement systems. Collectively, these applet tags form TransitionSensor applet 210. This script, as described in detail below and isreproduced in Table 2 below, when interpreted and executed by a Javavirtual machine (Java interpreter) resident in the browser persistentlyloads and then instantiates the Transition Sensor itself which, in turn,loads and instantiates the remainder of the agent in the client browser.TABLE 2 TRANSITION SENSOR APPLET <appletcode=“com.unicast.adcontroller.tools.TransitionSensor”codebase=“http://www.unicast.com/java/classes/” align=“baseline”width=“0” height=“0” name=“TransitionSensor” archive=“adcontroller.jar”><param name=“adURL”value=“http://www.unicast.com/media/fireworks_01_ad_descriptor.txt”><param name=“cabbase” value=“adcontroller.cab”> </applet>

[0093] The value of attribute CODE in the Transition Sensor appletspecifies a Java executable that will be executed by the client browser,when it renders this applet, to launch the Transition Sensor. Theexecutable, implemented through an appropriate Java class, wasoriginally compiled from its associated Java source code file. Tagslabeled “<WIDTH>” and “<HEIGHT>” jointly specify a rectangular portionof a web page, as displayed by browser 7, in which the applet will berendered. Since, here that portion is non-existent, nothing will berendered. Applets, such as this one, can be delivered transparently overthe Internet to the client PC and require no user-assisted installation.

[0094] Another portion of the advertising tag(“AdServer=”http://AdManagement_system”) references a URL of aparticular ad management system (where “AdManagement_system” representsa web address (URL) of that particular system), here illustrativelysystem 25, from which the agent is to download an advertisement. As willbe seen below, the Transition Sensor applet, during its execution,passes this URL, as part of an advertising download request, to theremainder of the AdController agent to subsequently download appropriateadvertising files, also as described below, from that system necessaryto interstitially play an advertisement.

[0095] If advertisements are to play on client browsers (specificallyMicrosoft Internet Explorer version 3) that do not support dynamicwriting of applet tags, then applet 210 would need to be inserted bycontent providers into each referring web page in lieu of advertisingtag 40. Unfortunately, Transition Sensor applet 210 identifies both theagent server, and an actual advertisement in terms of a URL of itssource components (through contents of an “AdDescriptor” file—which willbe discussed in detail below—specified in this applet). Since browsertechnology continues to rapidly advance with most users continuallyupgrading their browsers, most browsers now in use, and in a very shorttime nearly all such browsers, will support such dynamic writing. Hence,we see little, and very shortly essentially no need, to embed applet 210into any referring web pages, thus minimizing ad insertion cost, effortand time while restricting disclosure of the agent server andadvertisement source information.

[0096] The agent, during its execution, “politely” and transparentlydownloads advertising files (media, and where necessary player files),originating from ad management system 25 for a given advertisement intobrowser disk cache (with the media files also being written into browserRAM cache) and subsequently plays those media files through the browseron an interstitial basis and in response to the user click-stream.

[0097] Advantageously, the agent operates independently, in the clientbrowser, of the content in any referring web page. Once loaded andstarted, the agent executes in parallel, with standard browserfunctionality, continually and transparently requesting and downloadingadvertisements to a browser disk cache residing on a local hard disk(“browser disk cache”), as well as in the case of media files intobrowser RAM cache, in a client computer (e.g., personal computer—PC) andinterstitially playing those advertisements.

[0098] Now, with the above in mind and specific reference to FIGS. 1Band 1C, we will now describe the basic inter-computer actions associatedwith use of our invention, as well as the basic attendant processingsteps that occur in the client PC.

[0099] To begin a browsing session, the user first invokes clientbrowser 7. Once the browser is executing, the browser obtains, as aninitial web page—selection of this page being referenced by numeral 31,an address either of a prior so-called “default” content page previouslyspecified by the user and having its URL stored in the browser or of acontent page manually entered by the user. The client browser thenissues, as symbolized by block 33, a request to fetch a file for thatpage; with the request containing a URL of that page (i.e., its completeweb address including its file name). We assume for simplicity that thefile for that page resides on web server 13. We also assume that page 35is being requested which will invoke an associated interstitialadvertisement in accordance with our invention. In response to therequest routed to server 13—as symbolized by line 34, this particularserver downloads, as symbolized by line 36, to client PC 5 a file forpage 35, where the coding stored in this file contains advertisement tag40. Illustrative contents of this tag are shown in dashed block 45, aswell as in FIGS. 2A and 2B.

[0100] Once this file is received as shown in FIGS. 1B and 1C, browser 7interprets and then executes, as symbolized by block 52, the HTML codein page 35, which includes tag 40 and thus undertakes the actions shownin agent download/instantiate/execute operations 50. These operationseventually result in the AdController agent being downloaded,instantiated and started in the client browser. Generally speaking, thebrowser in response to executing the advertising tag, issues a request,as symbolized by line 54, to agent server 15 to download theAdController agent. Through various several inter-processing operations,as shown in further detail in FIGS. 1E and 1F and which will bedescribed below shortly, server 15 accesses and downloads, as symbolizedby line 56, the needed files to install the AdController agent toexecute under browser 7 on the client PC. Once files for the agent aredownloaded to the browser disk cache on the client PC, the browser theninstantiates and starts the agent executing, as symbolized by block 58.Operations 50 effectively conclude once the agent begins executing.

[0101] Now referring to operations 50 as shown in further detail inFIGS. 1E and 1F, upon entry into these operations, browser 7 executes,as symbolized by block 110, advertising tag 40. The browser then issuesa request, as symbolized by line 115, to agent server 15, to download aJavaScript file (named, e.g., “loadad.js”) specified in the request.This file is specified as the first portion of the advertising tab. Inresponse to this request, server 15 downloads, as symbolized by line120, this particular file onto browser 7 where that file is cachedappropriately. Once the file is fully downloaded, it is interpreted andexecuted by a Java virtual machine (a Java interpreter integrated intothe browser and which generates code compatible with and executable bythe browser). As indicated by block 125, the browser then executes theinterpreted code for the script which, in turn, dynamically writesapplet tags—in the manner generally shown in FIGS. 2A and 2B anddescribed above—into web page 35 in lieu of the advertising tag. Thesetags, which collectively form Transition Sensor applet 210, include areference to a specific ad management system as specified in the secondportion of advertising tag 40.

[0102] Once these tags are dynamically written into content web page 35(to yield modified version 35′ shown in FIGS. 2A and 2B), TransitionSensor applet 210 is instantiated and then executed. In particular,browser 7 determines whether executable code for the Transition Sensorapplet has been previously downloaded to the browser disk cache. If thiscode has not been downloaded or an updated version of this code existson agent server 15, the browser issues, as symbolized by line 130, arequest to download a latest version of the Transition Sensor executablecode from the agent server. Server 15, in response to this request,downloads, as symbolized by line 135, file(s) for the latest version ofthe transition sensor code to the browser which, in turn, stores thesefile(s) into the browser disk cache. Thereafter as symbolized by block140, the browser instantiates and starts execution of the TransitionSensor applet. This latter applet, as part of its initial execution,instantiates an Applet Registry. This registry provides a mechanism,within the agent, for inter-applet communication between the constituentTransition Sensor and AdController applets.

[0103] Thereafter, the Transition Sensor applet attempts to load, alsoas symbolized by block 140, the AdController applet, through thebrowser, from the browser disk cache. To do so, the browser firstdetermines whether the AdController applet has been downloaded to thebrowser disk cache or whether an updated version of this particularapplet resides on agent server 15. If an updated version of this appletexists on the agent server relative to that previously downloaded to thebrowser disk cache or if the AdController applet has not been downloadat all into this cache, the browser issues a request, as symbolized byline 150, to download a latest version of the AdController applet fromagent server 15. Server 15, in response to this request, downloads, assymbolized by line 155, file(s) for the latest version of theAdController applet to the client browser which, in turn, stores thesefile(s) into the browser disk cache. Lastly, as symbolized by block 160,the Transition Sensor applet then instantiates and starts theAdController applet; and thereafter establishes appropriate entries inthe Applet Registry for itself and the AdController applet.

[0104] Returning to FIGS. 1B and 1C, once operations 50 have completed,such that the agent is executing under browser 7, the AdControllerapplet issues, as symbolized by block 60, a request, via agent server15, to download an AdDescriptor file from the ad management system,e.g., ad management system 25, specified in advertising tag 40. Thisrequest contains the URL of the ad management system contained inadvertising tag 40. Currently, Java applets are restricted underconstraints inherent in the Java programming language itself toretrieving files from an identical Internet host that served the appletitself. As such, rather than directing this request to advertisingserver 20, on which ad management system 25 resides, this request, assymbolized by line 62, is addressed to agent server 15, which serves asa proxy server between client PC 5 and advertising server 20. Both therequest and resulting advertising (including media and player) fileswill be served to the client PC through agent server 15. As such, oncethe request has been received by the agent server, this server passesthe request onward, as symbolized by line 64, to advertising server 20.

[0105] In response to this request for an AdDescriptor file, admanagement system 25 then selects a specific advertisement to bedelivered to client PC 5. This selection can be selected on a predefinedor random basis, or based on user preference or other user-specificinformation previously collected from and associated with the user thenoperating browser 7. Such user-specific information, such as priorbuying patterns, could have been appropriately pre-collected at theclient PC, previously uploaded to ad management system 25 and processedthere such that, upon receipt of the AdDescriptor request, system 25would then select and download an appropriate advertisement specificallytargeted to the user then situated at the client PC. In any event, oncesystem 25 selects the advertisement, through whatever selection metricit employs, the corresponding AdDescriptor file is then downloaded, assymbolized by line 66, to agent server 15 (here being a proxy server)which, in turn, as symbolized by line 68, supplies that file to theAdController agent then executing under web browser 7.

[0106] To digress slightly, for the selected advertisement, theAdDescriptor file is a text file that contains a manifest, i.e., a list,of file names and corresponding network locations (URLs) at which thesefiles reside, and player instructions and configuration parameter valuesnecessary to play the entire advertisement through web browser 7 to theuser. FIG. 20 shows contents of typical AdDescriptor file 2000 for aPointCast Java advertisement. Specifically and as shown in section 4C offile 2000, this AdDescriptor file lists file names with partialaddresses on the ad management system of all media files that constitutecontent for that advertisement, and, in section 1 of this file, all Javaplayer files necessary to play all the media files. This file alsorespectively specifies, here shown in section 3 and 4B, an order inwhich the various media files are to be played, and variousconfiguration parameters need to properly configure the operation ofeach player to play each corresponding media file.

[0107] The AdDescriptor file implements a data abstraction that totallyseparates the media and player files from the referring web page, herepage 35, thus assuring that the advertisement content itself remainscompletely independent of the content web page that invoked itspresentation. This abstraction permits our technique to provide a highlyeffective, generalized and very flexible mechanism for delivering richweb advertisements, particularly those that require complex sets ofmedia files and players. Through use of this abstraction, our inventivetechnique can handle present and future media formats, regardless oftheir requirements, including proprietary streaming and other contentdelivery technologies that rely on Java applets as a deliverymechanism—all transparently to the user. Moreover, the AdDescriptor filecan contain separate listings (though not contained in file 2000 shownin FIG. 20) that delineate media and player files for differentbrowsers, client operating systems or computing platforms (to the extentany of these require different versions of the media and/or playerfiles) then in use. As such, our technique can readily function with awide variety of different client computers and browsing platforms.

[0108] Once the AdDescriptor file is downloaded to the client PC, viaagent server 15, the AdController then “politely” downloads, assymbolized by block 70 shown in FIGS. 1B and 1C, into the browser diskcache each media and player file, as specified in the AdDescriptorfile—to the extent that file does not already reside on the hard disk ofthe client PC. Through so-called “polite” downloading, media and playerfiles are downloaded to browser 7 during browser idle time intervals,with the downloading suspended during each ensuing interstitial intervalafter the user instructs browser 7 to navigate to a new content webpage. In this manner, while a fully downloaded advertisement isinterstitially played from browser cache, the new content page isdownloaded over the full bandwidth of communications link 9.Advantageously, the communications link is freed during eachinterstitial interval to just carry web page content, thereby expeditingdownload of content pages. If, due to the occurrence of an interstitialinterval, the AdController applet suspends downloading of anadvertisement file, then upon termination of this interval, this appletthen resumes downloading at a location in that file at which downloadinghad stopped, thus conserving communication bandwidth and reducingdownload time.

[0109] In particular, as part of the operations symbolized by block 70,the AdController applet determines which files, of those listed on theAdDescriptor, do not then reside on the hard disk of client PC 5. Onceit has made that determination, this applet issues a request, assymbolized by line 72, to agent server 15, to fetch a first one of thesefiles. The agent server, again serving as a proxy server, issues arequest, as symbolized by line 74, to fetch this file from a networkedserver, anywhere on Internet 10, on which that file resides. Forsimplicity, we assume that all such files reside on server 20 and areaccessible through ad management system 25. Hence, system 25, via server20, issues a response, as symbolized by line 76 to agent server 15,containing this first advertisement file. The agent server, in turn andas symbolized by line 78, downloads this particular file to clientbrowser 7 for storage in the browser disk cache. Downloading ofadvertisement files continues in this manner until, as symbolized byline 88, a last required file for the advertisement has been downloaded,via agent server 15, to the browser disk cache on client PC 5.

[0110] As the advertisement files for a common advertisement are beingdownloaded, the Transition Sensor applet also monitors, as symbolized inblock 90, a click-stream produced by the current user so as to detect auser-initiated page transition. Once such a transition occurs, usuallycaused by a user engendered mouse click, and hence an interstitialinterval starts, the AdController applet plays, also as symbolized byblock 90, a fully cached advertisement (assuming all its media andplayer files have been downloaded) in the manner specified in itsassociated AdDescriptor file and using the players specified therein.Also, at the inception of the interstitial interval, the browser issues,also as symbolized by block 90, a request to fetch the next successiveweb page to which the user desires to transition. Once the advertisementhas fully played, or until the next successive content web page is fullydownloaded and assembled, or a user has closed an advertisement window,whichever occurs first (assuming the AdDescriptor file specifies thatthe advertisement can be prematurely terminated), then control isreturned, as symbolized by path 94, to the client browser to awaitcompletion of the download and interpretation of HTML code that formsthat next content page and subsequent execution, of an advertising tagtherein to invoke agent download/instantiate/execute operations 50 forthat page; and so forth.

[0111] The Transition Sensor and AdController applets are eachimplemented through appropriate Java classes and collectively persist,through storage in the browser disk cache, across different contentpages within a site, different web sites, and successive browsersessions. Once either of these applets is completely downloaded throughoperations 50, providing that applet is not subsequently flushed fromthe browser disk cache as the user navigates across web sites on theweb, the files for that applet will be loaded from that cache, ratherthan being downloaded from agent server 15, the next time that applet isrequired, e.g., when the user next navigates, either during a currentbrowser session or a subsequent session, to any successive content pagethat contains advertising tag 40.

[0112] Whenever client browser 7 encounters a next successive contentpage containing advertising tag 40, then the browser, will first andautomatically inquire with agent server 15 to ensure that executablecode for the Transition Sensor applet, if previously downloaded into thebrowser disk cache, has not been superseded by an updated version. Ifsuch an updated version then exists, the browser will collectivelydownload updated files from the agent server and replace, to the extentnecessary, each Transition Sensor applet file residing in the browserdisk cache with its updated version. Alternatively, if the TransitionSensor applet has not been previously downloaded into the browser diskcache, then the browser will download all the necessary files for theTransition Sensor applet from the agent server into that cache. TheTransition Sensor applet, once executing, will load, through thebrowser, the AdController applet. To do so, the browser will, ifnecessary, obtain an updated version, from the agent server, in the samemanner as it did for the Transition Sensor. As a result, any correctionsor enhancements made to the agent (specifically the Transition Sensorand/or the AdController applets) since the agent was last downloaded tothe client browser will be automatically and transparently, from a userperspective, distributed to that browser and downloaded into that diskcache the next time the browser encounters a web page containing anadvertising tag. By operating in this fashion, the user is totally andadvantageously relieved of any need to: both initially load and installan application program to obtain advertising and/or later update thatprogram.

[0113] Specifically, cross page persistency of the Transition Sensoragent is accomplished by using a Java “singleton” design. A singletondesign allows only a single object to ever be created and isaccomplished by declaring a Java class as static. Since all applets runin a same instance of a Java virtual machine, therefore all applets andtheir associated code share all static class variables. A static AppletRegistry class is instantiated automatically by the Transition Sensorapplet at its run time and, by implementing the Applet Registry,provides all inter-applet communication between the Transition Sensorand the AdController applets and their threads. The Applet Registryclass implements a “loadAdController” method which, in turn,instantiates the persistent AdController applet. Through this method,the Transition Sensor applet downloads the AdController applet only ifthe latter applet has either been updated, relative to that version ofthis applet then resident in the browser disk cache, or does not thenreside on the browser disk cache. The AdController applet theninstantiates all its own threads that collectively implement transparentadvertisement downloading and play mechanisms.

[0114] The AdController applet is itself created by an Applet Registrysingleton object and creates all other objects that collectivelyconstitute a run time agent execution module. This applet extendsstandard applet class definitions by over-riding standard Java appletinit (initialize), start, run, stop and destroy life cycle methods,conventionally implemented in the client browser, with correspondingsubstitute methods. The substitute stop method ensures that atraditional response provided by the browser of halting execution foreither the AdController applet does not occur whenever the browser callsthe stop method to terminate the lifecycle of this applet; hence,advantageously providing persistence to the agent across successivecontent pages. Consequently, the agent continues executing until theuser terminates execution of (closes) the browser itself.

[0115] Thus, the agent persists and functions transparently inbackground, independent and transparent to user navigation across pageson a common web site and across web sites. In that regard, the agenteffectively implements a background process which runs in parallel withand is transparent to normal HTML and HTTP operations implemented by theclient browser.

[0116] To significantly simplify the description and the accompanyingdrawings, we have intentionally omitted from this discussion specificJava classes that constitute the AdController agent as well as, toincrease a rate at which advertisements can be queued for playback, anaccompanying software architecture for processing these classes on amulti-threaded pipelined basis. Such details are conventional in nature;hence, their use in implementing our present invention would be readilyapparent to any one skilled in the art.

[0117] B. Client PC

[0118]FIG. 3 depicts a block diagram of client PC 5.

[0119] As shown, the client PC comprises input interfaces (I/F) 320,processor 340, communications interface 350, memory 330 and outputinterfaces 360, all conventionally interconnected by bus 370. Memory330, which generally includes different modalities, includingillustratively random access memory (RAM) 332 for temporary data andinstruction store, diskette drive(s) 334 for exchanging information, asper user command, with floppy diskettes, and non-volatile mass store 335that is implemented through a hard disk, typically magnetic in nature.Mass store 335 may also contain a CD-ROM or other optical media reader(not specifically shown) (or writer) to read information from (and writeinformation onto) suitable optical storage media. The mass store storesoperating system (O/S) 337 and application programs 400; the latterillustratively containing browser 7 (see, e.g., FIGS. 1B and 1C) whichimplements our inventive technique. O/S 337, shown in FIG. 3, may beimplemented by any conventional operating system, such as the WINDOWSNT, WINDOWS 95, or WINDOWS 98 operating system (“WINDOWS NT”, “WINDOWS95” and “WINDOWS 98” are trademarks of Microsoft Corporation of Redmond,Wash.). Given that, we will not discuss any components of O/S 337 asthey are all irrelevant. Suffice it to say, that the browser, being oneof application programs 400, executes under control of the O/S.

[0120] Incoming information can arise from two illustrative externalsources: network supplied information, e.g., from the Internet and/orother networked facility, through communication link 9 to communicationsinterface 350, or from a dedicated input source, via path(es) 310, toinput interfaces 320. Dedicated input can originate from a wide varietyof sources, e.g., an external database. In addition, input information,in the form of files or specific content therein, can also be providedby inserting a diskette containing the information into diskette drive334 from which client PC 5, under user instruction, will access and readthat information from the diskette. Input interfaces 320 containappropriate circuitry to provide necessary and corresponding electricalconnections required to physically connect and interface each differingdedicated source of input information to client PC 5. Under control ofthe operating system, application programs 400 exchange commands anddata with the external sources, via network connection 9 or path(es)310, to transmit and receive information typically requested by a userduring program execution.

[0121] Input interfaces 320 also electrically connect and interface userinput device 395, such as a keyboard and mouse, to client PC 5. Display380, such as a conventional color monitor, and printer 385, such as aconventional laser printer, are connected, via leads 363 and 367,respectively, to output interfaces 360. The output interfaces providerequisite circuitry to electrically connect and interface the displayand printer to the computer system.

[0122] Furthermore, since the specific hardware components of client PC5 as well as all aspects of the software stored within memory 335, apartfrom the modules that implement the present invention, are conventionaland well-known, they will not be discussed in any further detail.Generally speaking, agent server 15 and third-party ad server 20 eachhas an architecture that is quite similar to that of client PC 5.

[0123] C. Software

[0124] 1. Application Programs 400

[0125]FIG. 4 depicts a simplified high-level block diagram ofapplication programs 400 resident within the client PC.

[0126] As shown, the application programs, to the extent relevant,contain browser 7 and resident JAVA player files 410, i.e., files forJAVA media players that have previously been installed onto the harddisk of the client PC. These players may illustratively include audio,streaming audio, video and multi-media players.

[0127] Browser 7 contains AdController agent 420, when it has been fullyloaded for execution into browser cache, browser disk cache 430 and Javavirtual machine 440 (which has been discussed above to the extentrelevant). As noted, this agent persists whenever the user causesbrowser 7 to transition across different web content pages or differentweb sites, and functions independently and transparently of any suchpages and sites. The AdController agent includes applet registry 426 forfacilitating inter-applet communication within the agent.

[0128] The AdController agent contains two applets Transition Sensorapplet 422 and AdController applet 424. As discussed above, theTransition Sensor applet accomplishes three basic functions. First, thisapplet loads, instantiates and starts the AdController applet. Second,the Transition Sensor applet communicates an Internet address of anadvertising server, here server 20, to request an advertisement,specifically an AdDescriptor file therefor, that is to be downloaded andsubsequently presented. Lastly, the Transition Sensor applet, throughassociated click-stream monitoring (performed by a Transition Sensorimplemented by this applet), determines when a user situated at clientbrowser 7 undertakes an affirmative action, such as, e.g., causing amouse click, to request a next successive web page be downloaded andrendered, and so notifies the AdController agent of that event. Thisevent signals a start of an ensuing interstitial interval.

[0129] AdController applet 424, which is not embedded in any contentpage, executes under but is not controlled by browser 7. This applet,also as discussed above, accomplishes several basic functions. First, itcreates all other objects that collectively form a run time agentexecution module for the agent. As noted above, this includes extendingstandard Java applet class definitions by over riding standard Javaapplet init, start, run, stop and destroy life cycle methods. Second,the AdController applet “politely” downloads advertising (includingmedia and, where necessary, player) files, through the client browserexecuting at a client computer, into browser disk cache and in a mannerthat is transparent to a user situated at the browser. Lastly, theAdController applet interstitially plays advertisements through theclient browser in response to the user click-stream associated withnormal user navigation across different web pages.

[0130] Browser disk cache 430 stores downloaded AdDescriptor files 433and accompanying and downloaded media and player files 437.

[0131] 2. AdController Agent 420

[0132]FIG. 5 depicts a high-level block diagram of AdController agent420.

[0133] As shown, the agent specifically contains Transition Sensorapplet 422, AdController applet 424 and applet registry 426.

[0134] As discussed generally above, the Transition Sensor appletimplements, as one of its functions, a transition sensor which detects,through user navigation click-stream monitoring, a user-initiatedtransition to a new web page, and produces, in response, a correspondingTransition Sensor event. Such a transition occurs in response to anactual user initiated mouse click or key depression to activate ahotlink appearing on a currently displayed content page in order to moveto new content page, either on the same site or on another site. Anothersuch transition occurs whenever a stored history of web pages justvisited by the user changes state. The latter is sensed by a JavaScriptfunction that monitors a history stored in browser disk cache 430 ofvisited web page URLs and generates an event whenever the historychanges state. For ease of reference, we will collectively define theterm “click-stream” to encompass any user-initiated transition to a newcontent page, whether it is a mouse click, key depression or historystate change.

[0135] Transition Sensor events are used to trigger the play of anadvertisement only if, by then, all the media and player files for thatadvertisement have been fully cached into browser disk cache 430.Otherwise, play of that advertisement is deferred until after all thosefiles are cached and the advertisement is ready to be rendered and,importantly, in response to the next user-initiated transition.

[0136] Client browser 7 produces init (initialize) and start and stopTransition Sensor events, as symbolized by line 505 and 510,respectively. The init and start events are produced by the browser toinitialize (i.e., load and instantiate) and start the Transition Sensorapplet. The stop events are also produced by the browser, though througha Transition Sensor stop method which has been substituted for astandard browser stop method, in response to detection, by theTransition Sensor, of user-initiated page transitions. These eventscontrol the state of applet 422. Transition Sensor applet 422communicates directly with AdController applet 424, as symbolized byline 535—such as to pass an Internet address of an advertising server,and indirectly, as symbolized by line 530, through applet registry 426.Registry 426 passes information, as symbolized by line 540, toAdController applet 424.

[0137] As noted above, AdController applet 424 extends standard Javaapplet class definitions by over riding standard Java applet init,start, run, stop and destroy life cycle methods. By doing so,particularly in the case of the Stop method (which will be describedbelow in conjunction with FIG. 18), permits the AdController applet topersist in browser disk cache 430 as the user navigates, acrosssuccessive pages and web sites.

[0138] Advantageously, the AdController applet can readily function in awide variety of environments, without changes to the coding of theapplet itself. This is accomplished through downloading of an externalconfiguration file (specifically file 620 shown in FIGS. 6A and 6B,which will be discussed below), as part of the applet files, from agentserver 15. Suitably changing parameter values in the configuration filepermits the behavior of applet 424 to be readily changed to suit adesired environment without a need to utilize a different version ofthat applet for each different environment, otherwise requiringdifferent software classes and with attendant modifications andre-compilation.

[0139] Execution of AdController applet 424 begins by Transition Sensorapplet 422 calling a standard init Applet method, which downloads theexternal configuration file followed by extracting and saving itsconfiguration parameters. These parameters are supplied, as symbolizedby line 515, to the AdController applet, during its execution in orderto define its behavior given its current execution environment.

[0140] As noted above, AdController applet 424 “politely” andtransparently downloads advertising (including media and, wherenecessary, player) files, through browser 7 into browser disk cache 430,for each and every advertisement that is to be subsequently andinterstitially played. A data path through which advertisements aredownloaded is shown in FIG. 5 by dot-dashed lines; while that foradvertisement play is shown in this figure by dotted lines.

[0141] Specifically, to download and play advertisements, applet 424implements Ad Pipeline 545 (which will be discussed in detail below inconjunction with FIG. 14). Pipeline 545 implements various threads(processes) and data structures which collectively load advertisingfiles into browser disk cache 430 (and, for media files, also intobrowser RAM cache) and then present fully downloaded advertisements. Thepipeline implements Ad Producer, Ad Location and Ad Downloader processes(processes 1500, 1600, 1700 shown in FIGS. 15, 16 and 17, respectively,and discussed in detail below), and download queue 1430 and play queue1470 (both of which are shown in FIG. 14 and discussed in detail below).

[0142] In essence, once Transition Sensor applet 422, as shown in FIG.5, supplies AdController applet 424 with a URL of an AdDescriptor file,Ad Pipeline 545 then downloads, as symbolized by dot-dashed line 520,the AdDescriptor file, via agent server 15 (serving as a proxy server),from a remote advertising management system. As noted above, this filecontains a manifest of media and player files necessary to fully play acomplete advertisement. Once this AdDescriptor file has been downloadedinto Ad Pipeline 545, pipeline 545 then “politely” downloads, assymbolized by line 525, each file specified in the manifest—to theextent that file does not already reside on the client hard disk.Pipeline 545 writes the AdDescriptor file to the play queue and eachdownloaded file specified therein to browser disk cache 430; henceforming a queued advertisement for subsequent access.

[0143] At the inception of an interstitial interval, signaled by aTransition Sensor stop event, the AdController applet interstitiallyplays an advertisement that has then been completely queued—both interms of its media and player files. In particular, at the start of thatinterval, the Ad Pipeline retrieves an AdDescriptor that is thensituated at the head of a play queue. Media players 565 required by thatadvertisement, as specified in the AdDescriptor file, are started in theorder specified in that file along with their corresponding mediafile(s). A resulting processed media stream, produced by the player(s),and as symbolized by line 570, is rendered through browser 7 to theuser. Media players 565 may permanently reside, i.e., apart from beingdownloaded by agent 420, on the client hard disk (thus being implementedby resident player files 410 as shown in FIG. 4) or be downloaded bypipeline 545 into browser disk cache 430 (and also browser RAM cache)for subsequent access and use (thus stored within files 437 shown inFIG. 4).

[0144] Once an advertisement completely plays, AdController applet 424,as shown in FIG. 5, establishes an appropriate log entry for a “userimpression” for that advertisement. Advertisement files are retained inthe browser disk cache until that cache completely fills, at which pointthese files, like any other content files stored in that cache, aredeleted by the browser on a first-in first-out (i.e., age order) basis.Media players 565, browser 7 and browser disk cache 430 are all shown indashed lines as these components, while being used by the AdControlleragent, are not viewed as constituting components solely within the agentitself.

[0145]FIGS. 6A and 6B collectively depict a high-level flowchart ofprocessing operations 600 performed by AdController agent 420; thecorrect alignment of the drawing sheets for these figures is shown inFIG. 6. Though, the operations depicted in this figure—and also in FIGS.8, 9A and 9B, 12, and 14-19 —occur through a multi-threaded approach toprocess multiple advertisements on a pipelined basis, to simplify allthese figures, the sequential processing flow shown in each of thesefigures is that which processes a single common advertisement.Description of threads and classes is provided to the extent needed toprovide a sufficient understanding to those skilled in the art as to howthese sequential processing flows would preferably be implementedthrough a multi-threaded Java class methodology.

[0146] Upon entry into process 600 as shown in FIGS. 6A and 6B, whichoccurs in response to an Transition Sensor init event from browser 7,block 610 is performed. Through this block, Transition Sensor applet 422instructs the applet registry to load the AdController applet. Once thatoccurs, block 615 is performed through which external AdControllerconfiguration file 620 is retrieved from agent server 15. Thereafter,through decision block 630, agent 420 waits, by looping through NO path631, until browser 7 generates a Transition Sensor start event. Whensuch an event occurs, execution proceeds, via YES path 633 emanatingfrom this decision block, to block 635. Through this latter block,AdController applet 424 obtains an Internet address of an advertisementmanagement system (e.g., system 25) from which the agent is to retrieveAdDescriptor file 645. Applet 424 then passes this address to AdPipeline 545. The Ad Pipeline, as indicated in block 640, then retrievesAdDescriptor file 645 from this address, and through agent server 15serving as a proxy server. Once this file is retrieved, the agentperforms block 650 which “politely” downloads all the media and playerfiles 655 (to the extent each file does not already reside on the clienthard disk), from advertising management system 25 (residing onadvertising server 20), and, through block 660, stores these files intobrowser disk cache 430 (and, in the case of media files, into browserRAM cache). As noted above, these files are downloaded via agent server15, which here too serves as a proxy server. This downloading continuesuntil either it finishes or a Transition Sensor stop event generated bythe browser arises, whichever occurs first. As to the stop event,decision block 665 tests for its occurrence, with execution loopingback, via NO path 666, in the absence of such an event. However,whenever this event occurs, such as (as discussed above) in response toa user-initiation page transition, decision block 665 routes execution,via YES path 668, to block 670. This latter block then, using mediaplayers 565, plays an advertisement then fully queued in the play queueon the browser disk cache, i.e., an AdDescriptor file for this ad thenresides at a head of the play queue and all associated media and playerfiles for that advertisement, as specified in that AdDescriptor file,then reside on the client hard disk.

[0147] 3. AdController Applet 424

[0148]FIG. 7 depicts a high-level block diagram of basic executionthreads that implement AdController applet 424.

[0149] As shown, in response to a Transition Sensor init event producedby the client browser, one thread executes block 710 to initializeAdController applet 424. This block performs the downloading (to theextent necessary) and instantiation of applet 424. In response to aTransition Sensor start event produced by the client browser, anotherthread, by executing block 720, starts the AdController applet. Oncethis applet is started, this applet, in turn and as discussed above,through execution of block 730, enables downloading of advertising(media and player) files to commence. In response to an receivedInternet address of a remote ad management system (here, e.g., system 25shown in FIGS. 1B and 1C) supplied by the Transition Sensor applet, athird thread requests, through execution block 740 shown in FIG. 7, anAdDescriptor file from the ad management system situated at this addressand then downloads AdDescriptor file 645 received in response. If, bythis time, block 730 has enabled advertisement downloading, thenadvertising files, as specified in AdDescriptor file 645, are “politely”downloaded as required. In response to a Transition Sensor stop eventproduced by the client browser and which signals an inception of aninterstitial interval, another thread, here commencing with execution ofblock 750, suspends downloading of advertisement files in favor ofdisplaying a queued advertisement. Once this downloading is suspended,this last thread invokes block 760 to commence play of an advertisementthen situated, in terms of its AdDescriptor file, at a head of the playqueue.

[0150]FIG. 8 depicts a high-level flowchart of processing operations 800performed by AdController applet 424.

[0151] Upon entry into operations 800, which occurs in response to aninit event produced by the Transition Sensor applet, block 810 isperformed. Through this block, the AdController applet is initialized.This includes downloading files, to the extent needed, for this appletfrom the agent server and then instantiating this applet. Once thisoccurs, block 810 tests for an occurrence of AdController start eventproduced by the Transition Sensor applet. Until this event occurs,execution merely loops back, via NO path 812, to block 810. When thisevent occurs, decision block 810 routes execution, via YES path 814, toblock 815. This latter block, retrieves external AdControllerconfiguration file 620 from the agent server. Thereafter, block 820occurs through which the AdController applet creates and starts AdPipeline 545. Once the pipeline is fully started, then, block 825 isperformed to enable advertisement files to be “politely” downloaded intothe ad pipeline and to thereafter actually download such files. Whileadvertisement files are being downloaded or thereafter, if suchdownloading has completed, decision block 830 tests for an occurrence ofa Play Ad event. If no such event occurs, then execution loops back, viaNO path 833, to decision block 830 to continue any further downloading.If however, a Play Ad event occurs, then decision block 830 routesexecution, via YES path 837, to block 840. This latter block suspendsfurther downloading of advertisement files into the Ad Pipeline. Oncethis occurs, then block 845, when performed, issues a request to the adpipeline to play an advertisement having its AdDescriptor file thenlocated at the head of the play queue. While the advertisement is beingplayed, decision block 850 tests for an occurrence of an shutdown eventgenerated by the browser, such as caused by, e.g., a user-initiatedtransition or the user closing an advertisement window or closing thebrowser itself. If such an event does not occur, decision block 850routes execution, via NO path 853, back to block 825 to re-enable“polite” download of advertisement files once again. If such a shutdownevent occurs, then processing operations 800 terminate, via YES path857.

[0152]FIGS. 9A and 9B collectively depict a flowchart of processingoperations 900 performed by AdController applet 424 specifically forprocessing an advertisement; the correct alignment of the drawing sheetsfor these figures is shown in FIG. 9.

[0153] Upon entry into operations 900, block 905 is performed to receivea request, issued by the Transition Sensor applet, to download a nextadvertisement, specifically an corresponding AdDescriptor file. Thisrequest contains an Internet address of a remote ad management system.In response to this request, AdController applet 424 performs block 910to request Ad Producer process (also being a thread) 1500 to download anad. The Ad Producer process, as will be discussed below in conjunctionwith FIG. 15, requests advertisement files, specifically an AdDescriptorfile, from an Internet address communicated by the Transition Sensorapplet. Thereafter, through block 915, the Ad Producer process blocks(i.e., it actively waits for its input data) until this process receivesthe Internet address of the remote advertising management system.Thereafter, block 920 executes to cause Ad Location process (also beinga thread) 1600 to block until such time as the AdDescriptor file isfully downloaded by Ad Producer process 1500 and is provided to the AdLocation process. Ad Location process 1600, as will be discussed belowin conjunction with FIG. 16, performs the following tasks: (a) onstartup of process 1600, this process creates an Ad Producer object; (b)it asks Ad Producer process 1500 for next AdDescriptor file 645; and (c)once process 1600 obtains such AdDescriptor file 645 and if downloadqueue 1430 (see FIG. 14) is not full, it writes that file into thisqueue. If this queue is then full, process 1600 simply waits until thequeue is not full before writing the AdDescriptor file into the queue.Once the AdDescriptor file has been completely downloaded, Ad Locationprocess 1600 inserts, as shown in block 925, this file into downloadqueue 1430.

[0154] Once AdDescriptor file 645 is inserted into the download queue,then Ad Downloader process (also being a thread) 1700 executes. Thisprocess, as will be discussed below in conjunction with FIG. 17,performs a single chain of tasks.

[0155] First, as shown by block 930, process 1700 blocks until such timeas the AdDescriptor file for the advertisement to then be downloadedbecomes available in the download queue. During its execution, thisprocess asks the download queue 1430 if there is an AdDescriptor filetherein, i.e., such a file for which advertising files need to bedownloaded. If the download queue is empty, then AdDescriptor process1700 both waits until that queue is not empty and also retrieves theAdDescriptor file over the network. Once the Ad Downloader process hasretrieved the AdDescriptor file, this process downloads, as shown byblock 940, all the advertising files specified in the AdDescriptor file,into browser disk cache (and, in the case of media files, into browserRAM cache), by using Browser Cache Proxy 1450 (see FIG. 14). Once allthe advertising files have finished downloading, this process, as shownin block 950, moves the AdDescriptor file to play queue 1470 (see FIG.14). However, if the play queue is then full, the Ad Downloader processwill wait until the play queue is not full before moving theAdDescriptor file into this queue.

[0156] The Browser Cache Proxy implements an interface to an abstractcache. The cache implementation could be any kind of cache—the browserdisk or RAM cache, a Java virtual memory cache, a local raw disk cache,and so forth. Once passed through this cache proxy, the media files thatconstitute an advertisement will have been downloaded into both disk andRAM cache of the browser. Whenever the Ad Downloader processsubsequently tries to access any media file having an identical URL tothat downloaded, this process will first attempt to load the files fromthe browser disk cache or browser RAM cache instead of downloading thefile, via the Internet, from its advertising management server; thusleveraging, even across different referring web pages or sites and tothe extent possible, a one time download of an advertising file acrossdifferent advertisements.

[0157] Next, should a Transition Sensor stop event occur, i.e.,indicative of a start of a next interstitial interval, then TransitionSensor stop method 1800 will request that AdController applet 424 thenplay an advertisement. In response to this request, an event schedulerthread within the applet will block, as shown in block 955, until suchtime as applet 424 responds to this request by initiating play of anadvertisement. The event scheduler thread controls playing ofadvertisements to the user. This process determines when to executemedia players specific to the next advertisement in the play queue(i.e., in terms of corresponding AdDescriptor files situated in thatqueue), as well as provides a callback method which the player executeswhen that player has successfully completed presenting an advertisementas specified in its corresponding AdDescriptor file. Once theAdController applet has initiated play of an advertisement, then, asshown by block 965, the event scheduler retrieves an advertisement,specifically the corresponding AdDescriptor file, then situated at thehead of the play queue. Thereafter, the event scheduler, as shown inblock 970, launches execution of the specific media player(s) 565 (seeFIG. 5), as specified in the corresponding AdDescriptor file, to playthis particular advertisement. The browser disk cache provides theassociated content files for this advertisement to the media player(s).Once the advertisement has been fully presented, then, as shown in block975, AdController applet 424 appropriately logs this presentation into alog file maintained in the browser disk cache for subsequent uploadingto the agent server. Execution then exits from operations 900.

[0158] A logger process (also implemented as a thread) keeps track ofall log entries that need to be sent back to the agent server. Thisprocess simply timestamps entries and adds them to a log buffer. Thenperiodically, the logger process will flush the log back to the agentserver where those entries can be archived and analyzed.

[0159] For an advertisement, player mechanisms take associated mediafiles specified in the associated AdDescriptor file from the browsercache and actually display these files to a user via a viewable frame orwindow. The user will view a pre-cached smoothly playing advertisementout of the browser disk cache and, where appropriate for media files,from browser RAM cache, rather than being streamed in over the Internet.Four modes for displaying advertisements are supported; namely,user-event triggered ad play, frame targeted ad play, timer based adplay and PopUp Java frame play. Each of these player mechanisms uses amedia player module (contained within media players 565 shown in FIG. 5)and a player thread. The player thread provides an actual presentationof advertising media to the user then operating the client browser. Thecombination of a player and a player thread provides capabilities of:controlling time-based frequency of advertisement play using an agentconfigurable timer; displaying of advertising media files in a browserwindow or Java frame; waiting a configurable amount of time (usually thelength of the advertisement as specified in its AdDescriptor file); andterminating the advertisement visually upon completion, or at a requestof the user if the advertisement, as configured in its AdDescriptorfile, permits pre-mature termination.

[0160] A frame targeted play renders advertisement media onto a browserwindow. Such play is interruptible and restartable upon user-demand.Timer based ad play utilizes a separate thread that continuously loopsto: obtain an AdDescriptor file from the play queue; display thatadvertisement using a player and player thread; and sleep for aspecified amount of time before repeating this sequence. Timer-based adplay is also interruptible and restartable upon user-demand. The resultof this type of advertisement play is that the user will periodicallyview advertisements delivered at regular time intervals rather than byuser initiated events. The PopUp Java frame play is a separate threadthat also continuously loops to: obtain an AdDescriptor file from theplay queue; waits for a signal that a user-initiated transition isoccurring; pops up a display window (“pop-up” window) in the browser,for a pre-defined period of time, and presents the advertisement in thatwindow; and removes the pop up window before repeating this sequence.The result of the PopUp Java Player is that the user will viewsuccessive advertisements each for pre-defined time interval (which canvary from one advertisement to the next, as specified in theAdDescriptor files for each such advertisement) whenever the usertransitions between one web page and the next. Once an advertisement iscompletely played and in the absence, as discussed above of anyinstructions in the AdDescriptor file to replay that advertisement, suchas through, e.g., timer-based ad play, the associated AdDescriptor fileis effectively “pulled off” the play queue.

[0161] In particular, downloading of advertisement files occurs, asdiscussed previously, continuously as effectively a background process,using a separate asynchronous thread. The stop method of the TransitionSensor (specifically Transition Sensor stop method 1800 as will bedescribed below in conjunction with FIG. 18) is responsible forgenerating a play event to the AdController agent. This event notifiesthe agent of an opportunity to present a downloaded advertisement to theuser. This stop method is called automatically by the client browserwhenever a user transitions off a web page that contains the embeddedadvertising tag. In particular, this method invokes a start playermethod in the AdController agent. The start player method, in turn,invokes a similarly named method, in the event scheduler, whichinitiates and controls the presentation of advertisements during contentpage transitions. The event scheduler ensures all media files for anadvertisement have been transparently downloaded before theirpresentation, as well as exercises control over actual execution of theappropriate player classes required to visibly render the advertisement.In that regard, the event scheduler instantiates and invokes a playerclass appropriate for the current advertisement by calling a startmethod of that class. This start method creates the player thread thatperforms visual rendering of the advertisement. Then, this start methodcalls a run method of the player thread in order to visually present theadvertising media from the browser disk and RAM caches. Upon completion,based on the configuration of the advertisement, the run method, byexecuting its own stop method, terminates the advertisement either upondetecting a close request by the user or completion of ad play timeout.The stop method performs any player software termination and cleanup,finally executing a callback to the scheduler object.

[0162] 4. Inter-applet Events Involving Transition Sensor Applet 422

[0163]FIG. 10 depicts inter-applet events 1000 that occur withinAdController agent 420 during execution of Transition Sensor applet 422.

[0164] As shown and discussed above, whenever a browser interprets andthen executes advertising tag 40, specifically tag 42 therein, situatedwithin content page 35, this causes the browser to download script 200(see FIGS. 2A and 2B) from the agent server. This applet, in turn,dynamically writes Transition Sensor applet 210 into the referring webcontent page. As discussed above, once this applet is instantiatedexecuted by the client browser, the applet, in turn, instantiates appletregistry 426.

[0165] Once the applet registry is instantiated, the Transition Sensorqueries the registry, this operation being symbolized by line 1015, todetermine current status of the AdController applet. If, as symbolizedby line 1020, the registry indicates that the AdController applet is notloaded and hence is not executing, then Transition Sensor applet 422loads, as symbolized by line 1025, AdController applet 424 from thebrowser disk cache, and then instantiates and starts this applet. Oncethe AdController applet is instantiated, the Transition Sensor appletwrites, as symbolized by line 1030, appropriate entries, indicating thatboth the Transition Sensor applet is loaded and, as symbolized by line1035, that the AdController applet is loaded, into the applet registry.Once this occurs, then the applet registry returns, as symbolized byline 1040, an appropriate handle for the AdController applet to theTransition Sensor in order to permit the latter to refer to the former.Thereafter, as symbolized by line 1060, the Transition Sensor passes, asdiscussed above and as symbolized by line 1060, a request containing anInternet address of an advertisement management system to theAdController applet to download an AdDescriptor file, for anadvertisement, from that address. This address is specified in tag 44 ofadvertising tag 40 and, as symbolized by dashed line 1050, incorporatedinto the request. Thereafter, the Transition Sensor, in response to auser-initiated transition (click-stream) to a next content web page,executes its stop method (method 1800 shown in FIG. 18) to instruct,i.e., issue a request to, as symbolized by line 1065, the AdControllerapplet to play a fully downloaded advertisement having its correspondingAdDescriptor file then situated at the head of the play queue. Once thisoccurs, the Transition Sensor applet terminates its execution until thebrowser next encounters, interprets and executes a content pagecontaining advertising tag 40 at which point the Transition Sensorapplet is re-loaded and re-started; and so forth.

[0166] 5. Transition Sensor Applet 422

[0167]FIG. 11 depicts a high-level block diagram of basic processingthreads that implement Transition Sensor applet 422.

[0168] As shown, in response to a Init (Initialize) Transition Sensorapplet event produced by the client browser, a thread commences byexecuting block 1110 to initialize Transition Sensor applet 422. Thisthread, in turn, executes block 1120 to load AdController applet 424from browser disk cache or download it from the agent server, ifnecessary, and then load it. Thereafter, this thread executes block 1130to obtain the Internet address of an advertising management system(e.g., system 25 shown in FIGS. 1B and 1C, 2A and 2B, and 10) in tag 44from advertising tag 40.

[0169] As shown in FIG. 11, in response to a Start Transition Sensorapplet event generated by the client browser, another thread commencesby executing block 1140 to enable Ad Downloader process 1700 (asdiscussed above, and to be discussed in detail below in conjunction withFIG. 17) to commence “polite” downloading an AdDescriptor file and allrequired and associated advertisement files (both media and player) intothe browser disk cache.

[0170] Further, as shown in FIG. 11, in response to a Stop TransitionSensor applet event generated by the client browser, a third threadcommences by executing block 1150 to disable Ad Downloader process 1700and thus suspend further downloading of advertisement files. Once thisoccurs, this thread then executes block 1160 to instruct theAdController applet to play a fully downloaded advertisement having itscorresponding AdDescriptor file then situated at the head of the playqueue.

[0171]FIG. 12 depicts a high-level flowchart of processing operations1200 performed by Transition Sensor applet 422.

[0172] Upon entry in operations 1200, decision block 1210 tests for anoccurrence of an init event produced by the client browser. Until suchan event occurs, execution loops back, via NO path 1213, to block 1210.When this event occurs, execution proceeds, via YES path 1217 to block1220 which, when performed, initializes Transition Sensor applet 422.Thereafter, block 1230 is performed through which the Transition Sensorapplet 424 instructs, by issuing a request to, the AdController appletto download an advertisement, specifically as discussed above anAdDescriptor file from an ad management server specified in theadvertising tag. Once this occurs, decision block 1240 tests for anoccurrence of a Transition Sensor start event generated by the clientbrowser. Until such an event occurs, execution loops back, via NO path1243, to block 1240. When this particular event occurs, executionproceeds, via YES path 1247 to block 1250 which, when performed, enablesAd Pipeline 545 to download the AdDescriptor file and associatedadvertising files.

[0173] Next, decision block 1260 tests for an occurrence of a TransitionSensor stop event generated by the client browser. Until such an eventoccurs, execution loops back, via NO path 1263, to block 1260. When aTransition Sensor stop event occurs, execution then proceeds, via YESpath 1267 to block 1270 which, when performed, requests thatAdController applet 424, specifically via Ad Pipeline 545, then play anadvertisement.

[0174] 6. Ad Loader Process 1300

[0175]FIG. 13 depicts a high-level block diagram of Ad Loader process1300 which forms a portion of AdController applet 424. Process 1300provides an advertiser (specifically an advertising programmer) withcontrol over various functions, for advertisement play and logging,implemented by the AdController applet, specifically how and where thisapplet retrieves advertisements across a networked connection and howthose advertisements are played. Through use of the Ad Loader, theAdController applet can be controlled, to an extent desired, by externalprogrammatic calls.

[0176] As shown, this process includes Ad Loader API (applicationprogramming interface) 1310 which interfaces to Ad Pipeline 545 andthrough this pipeline controls how advertisements are presented, assymbolized by block 1370, by the player mechanisms. In particular, theAd Loader API provides information regarding and, through settingvarious program variables, permits programmer control over advertisementdisplay and downloading operations. In that regard, these variablesprovide a callback to the AdController applet indicating when a contentpage to which the user has just transitioned has completed itsdownloading; and can be used to: instruct the AdController applet whento download a next advertisement, when to play a next advertisementfully queued in the Ad Pipeline, start and stop a play timer (for usewith, e.g., timer based ad play, as discussed above), log a message, seta mode so as to specify a desired location to display advertisements,suspend and resume download of advertisement files into the Ad Pipeline,suspend a current download for a given period of time, and suspend andresume advertisement play by the player mechanisms.

[0177] In that regard, the Ad Loader API configures Ad Pipeline 545 suchthat AdDescriptor file 645 is downloaded, as symbolized by block 1320,from a remote ad management system into the Ad Pipeline in response toreceipt of an Internet address of an ad management system and, fortargeted advertisements, a URL of a referring web page address. Assymbolized by block 1330, the API configures the Ad Pipeline such thatadvertisement downloading is enabled only when AdController applet 424is not playing an advertisement. Furthermore, as symbolized by block1340, the API configures the Ad Pipeline such that advertisementdownloading is disabled whenever the AdController applet is playing anadvertisement. Furthermore, as symbolized by block 1350, the APIconfigures the Ad Pipeline such that advertisement play is to commencein response to a request to play a next advertisement, i.e., one that isfully cached in the browser disk cache and having its AdDescriptor filethen situated at the head of the play queue.

[0178] 7. Ad Pipeline 545

[0179]FIG. 14 depicts a high-level block diagram of Ad Pipeline 545. Asdiscussed above, the Ad Pipeline implements various threads and datastructures which collectively load advertising files (needed media andplayer files) into the browser disk cache and, for media files, alsointo browser RAM cache, and then present fully downloadedadvertisements. As noted, the Ad Pipeline employs Ad Producer process1500, Ad Location process 1600 and Ad Downloader process 1700 (all ofthese processes, as noted above, are also threads).

[0180] In response to an incoming request to download an advertisement,Ad Pipeline 545 is invoked. Specifically, within this pipeline, firstblock 1410 executes to invoke Ad Producer process 1500 in response to anincoming request to download an advertisement. As discussed above, thisrequest, issued by the Transition Sensor applet, includes an Internetaddress of a remote ad management system (e.g., system 25 shown in FIGS.1B and 1C) on which an advertisement resides and is to be downloaded(through agent server 15 as a proxy server). Ad Producer process 1500,as will be discussed below in conjunction with FIG. 15, requestsadvertisement files, specifically an AdDescriptor file (e.g., file 645),from an Internet address specified in the request. During its execution,the Ad Producer process waits until it receives the Internet address ofthe remote advertising management system, whereupon this process thendownloads AdDescriptor file 645 from the specified ad management system.Once this file has been downloaded, block 1420, shown in FIG. 14,executes to invoke Ad Location process 1600 (which will be discussed indetail below in conjunction with FIG. 16). During its execution, AdLocation process 1600 blocks until such time as AdDescriptor file 645 isfully downloaded by Ad Producer process 1500 and is provided to the AdLocation process, whereupon the Ad Location process writes thisAdDescriptor file into download queue 1430.

[0181] After AdDescriptor file 645 has been written into the downloadqueue, Ad Location process 1600, as will be discussed below inconjunction with FIG. 16, performs the following tasks: (a) on startupof process 1600, this process creates an Ad Producer object; (b) thisprocess asks Ad Producer process 1500 for next AdDescriptor file 645;and (c) once process 1600 obtains AdDescriptor file 645 and, if downloadqueue 1430 is not full, process 1600 writes that file into this queue.If this queue is then full, process 1600 simply waits until the queue isnot full before writing the AdDescriptor file into the queue. Once theAdDescriptor file has been completely downloaded, Ad Location process1600 inserts, as shown in block 925, this file into download queue 1430.

[0182] Once AdDescriptor file 645 is inserted into the download queue,then Ad Downloader process 1700 executes. Process 1700, which will bediscussed below in conjunction with FIG. 17, performs a single chain oftasks. First, process 1700 blocks until such time as the downloadedAdDescriptor file has become available in the download queue. During itsexecution, this process asks download queue 1430 if it contains anAdDescriptor file, e.g., file 645. If so, then advertising files need tobe downloaded for that particular AdDescriptor file. If the downloadqueue is empty, then process 1700 both waits until that queue is notempty and also retrieves the AdDescriptor file over the network. Once AdDownloader process 1700 has obtained this AdDescriptor file, process1700 then downloads, all the media and required player files specifiedin the AdDescriptor file by using Browser Cache Proxy 1450, into browserdisk and RAM cache. Once all the advertising files have finisheddownloading, process 1700 moves the AdDescriptor file to play queue1470. However, if the play queue is then full, the Ad Downloader processwaits until play queue 1470 is not full before moving the AdDescriptorfile into this queue for subsequent ad play. As discussed above,AdDescriptor file 645 for a fully queued ad (i.e., with its all theassociated media and player residing on the client hard disk) issubsequently retrieved from play queue 1470 in response a request toplay an advertisement, this request being issued in response to aTransition Sensor stop event.

[0183] 8. Ad Producer Process 1500

[0184]FIG. 15 depicts a high-level block diagram of Ad Producer process1500. As noted above, this process requests an AdDescriptor file from anInternet address communicated by the Transition Sensor applet andsubsequently downloads that file in the browser disk cache.

[0185] As shown, upon entry into process 1500, execution first proceedsto decision block 1510. This block determines whether a URL has beenreceived, from the Transition Sensor, from which to fetch anAdDescriptor file. If such a URL has not yet been received, thenexecution loops back, via NO path 1517, to this decision block.Alternatively, if such a URL has been received, then execution proceeds,via YES path 1513, to block 1520 which, in turn, stores this URL, as AdURL 1530, for use during a next successive advertisement downloadopportunity

[0186] Once this URL has been so stored, execution proceeds to decisionblock 1540. This block tests for an occurrence of a user-initiated event(click-stream) signifying that advertisement downloading can now occur,such as, e.g., when the user has just closed an existing advertisementframe and a next successive content page to which the user hastransitioned is being rendered by the client browser. If such an eventhas not yet occurred, e.g., the next successive content web page isdownloading, then execution merely loops back, via NO path 1543, back todecision block 1540. However, if such an event occurs, then thisdecision block routes execution, via YES path 1547, to block 1550. Thislatter block, when executed, downloads AdDescriptor file 645 using theURL communicated by the Transition Sensor. Once this file is completelydownloaded, then block 1560 executes to transfer this file to AdLocation process 1600. Thereafter, execution loops back, via path 1565,to decision block 1510, and so forth.

[0187] 9. Ad Location Process 1600

[0188]FIG. 16 depicts a high-level block diagram of Ad Location process1600. This process, as discussed above, accomplishes the followingtasks: (a) on startup of this process, process 1600 creates an AdProducer object; (b) process 1600 asks Ad Producer process 1500 for nextAdDescriptor file 645; and (c) once process 1600 obtains AdDescriptorfile 645 and, if download queue 1430 (see FIG. 14) is not full, process1600 then writes that file into this queue. If this queue is then full,process 1600 simply waits until the queue is not full before writing theAdDescriptor file into the queue.

[0189] Upon entry into process 1600 and with respect to advertisementdownloading itself, execution proceeds to decision block 1610. Thisdecision block, when executed, determines whether an Internet address(URL) of an ad management system has been received from the TransitionSensor applet from which a next successive advertisement download. Ifthat address has not yet been received, then execution merely loopsback, via NO path 1613, to decision block 1610. Alternatively, if suchan address has been received but not yet processed, then decision block1610 routes execution, via YES path 1617, to block 1620. This latterblock requests Ad Producer process 1500 to download an AdDescriptorfile, e.g., file 645, from this URL. Once this request occurs, executionproceeds to decision block 1630 to determine whether this AdDescriptorfile has been completely downloaded. If this file download is stilloccurring, then execution merely loops back, via NO path 1633, to block1630 to await completion of the download. Once this download completes,decision block 1630 routes execution, via YES path 1637, to block 1640.This latter block writes the downloaded AdDescriptor file into downloadqueue 1430. Once this occurs, execution is directed, via path 1645, backto decision block 1610, and so forth.

[0190] 10. Ad Downloader Process 1700

[0191]FIG. 17 depicts a high-level block diagram of Ad Downloaderprocess 1700. Essentially, as discussed above, process 1700 determines,from the download queue, if it contains an AdDescriptor file, e.g., file645. If it does contain such an AdDescriptor file, then advertisingfiles need to be downloaded for that file. Consequently, process 1700then downloads required advertising files specified in that AdDescriptorfile. Once this fully occurs, process 1700 moves the AdDescriptor fileto the play queue.

[0192] In particular upon entry into process 1700, execution proceeds todecision block 1710. This decision block determines whether the downloadqueue then contains an AdDescriptor file, e.g., file 645. If the queueis empty, then execution merely loops back, via NO path 1717, to thisdecision block to await such an AdDescriptor file. However, if downloadqueue 1430 then contains such a file, process 1720 obtains theAdDescriptor file then situated at the head of this queue. Thereafter,block 1730 executes. This block downloads all the required advertisingfiles, not then resident on the client hard disk, into browser proxycache 1450. This block also transfers all the associated media files inthe browser proxy cache to the browser RAM cache. Execution thenproceeds to decision block 1740 which determines whether all requiredadvertising files have then been downloaded. If any such file remains tobe downloaded, then decision block 1740 routes execution, via NO path1747, back to block 1730 to download that file. Alternatively, if allthe required advertising files have been downloaded, then executionproceeds, via YES path 1743, to block 1750. This latter block moves theAdDescriptor file from download queue 1430 to an end of play queue 1470.Once the AdDescriptor file is written into the play queue, thecorresponding advertisement is then ready to be presented to the user,in order relative to other AdDescriptor files then queued in the playqueue, during an ensuing interstitial interval.

[0193] 11. Transition Sensor Stop Method 1800

[0194]FIG. 18 depicts a flowchart of stop method 1800 invoked byTransition Sensor applet 422. This method, in response to a stop eventgenerated by the browser, suspends downloading of advertisement filesand initiates interstitial ad play.

[0195] In particular, upon entry into method 1800, decision block 1810executes to determine if a stop event has been received from browser 7.If such a stop event has yet not occurred, then execution loops back,via NO path 1813, back to block 1810 to await occurrence of this event.When this event occurs, decision block 1810 directs execution, via YESpath 1817, to decision block 1820. This latter decision block determinesif AdController applet 424 is then loaded and executing. If this appletis not then executing, decision block 1820 routes execution, via NO path1827, to block 1830. This latter block inhibits any request from beingmade to the AdController applet to play any advertisement until thatapplet is executing and, once that occurs, a next user-initiated(click-stream) event occurs. Thereafter, execution of method 1800terminates. Alternatively, if the AdController applet is loaded andexecuting, then decision block 1820 routes execution, via YES path 1823,to block 1840. This latter block requests the AdController applet toplay a next advertisement. Once this request is issued, then executionproceeds to block 1850. This block, in turn, requests the AdControllerapplet to suspend “polite” background downloading of advertisement fileswhile a next successive web content page, as requested by the user, isbeing downloaded by the browser. Once block 1850 executes, execution ofmethod 1800 terminates.

[0196] 12. Transition Sensor Start Method 1900

[0197]FIG. 19 depicts a flowchart of start method 1900 invoked byTransition Sensor applet 422. This method, in response to a start eventgenerated by the browser, resumes background downloading ofadvertisement files.

[0198] Specifically, upon entry into method 1900, execution proceeds todecision block 1910 which, when executed, determines if a start eventhas been received from browser 7. If such a start event has not yetoccurred, then execution loops back, via NO path 1913, back to block1910 to await occurrence of this event. When this event occurs, decisionblock 1910 directs execution, via YES path 1917, to decision block 1920.This latter decision block determines if AdController applet 424 is thenloaded and executing. If this applet is not then executing, decisionblock 1920 routes execution, via NO path 1927, to block 1930. Block 1930inhibits any request from being made to the AdController applet todownload any advertisement until that applet is executing and, once thatoccurs, a next user-initiated (click-stream) event occurs. Once theAdController applet begins executing and thereafter a nextuser-initiated (click-stream) event occurs, execution proceeds to block1940. This latter block requests the AdController applet to resumebackground downloading of advertisement files. Once this downloading isresumed, method 1900, through execution of block 1960, waits for browser7 to call Transition Sensor stop method 1800 whenever the user nextunloads a web page currently rendered by the browser, i.e., causes auser initiated-event to transition to a next successive web page.Alternatively, if the AdController applet is loaded and executing, thendecision block 1920 routes execution, via YES path 1923, to block 1950.Since at this point the next successive content web page has been fullyexecuted by the browser and is, e.g., rendered to the user, block 1950issues a request, through the applet registry, to the AdControllerapplet to enable it to resume background downloading of advertisementfiles. Once this occurs, block 1940 is executed to issue a request tothe AdController applet to resume the background downloading. Executionthen proceeds to block 1960 to wait for browser 7 to call TransitionSensor stop method 1800 whenever the user next unloads a web pagecurrently rendered by the browser, i.e., causes a user initiated-eventto transition to a next successive web page. Whenever the browsergenerates a next Transition Sensor stop event, process 1900 terminates.

[0199] Although a single embodiment which incorporates the teachings ofour present invention has been shown and described in considerabledetail herein, those skilled in the art can readily devise many otherembodiments and applications of the present invention that still utilizethese teachings.

We claim:
 1. A computer readable medium storing a web page wherein theweb page comprises a plurality of computer readable instructions, theinstructions representing page content and an embedded advertising tag,wherein the advertising tag when executed by a web browser, causes thebrowser to: download from a server, at least one media file forming apredefined advertisement, while the browser is displaying a content webpage to a user; and during an interstitial interval occurring inresponse to a user-initiated event for transitioning between successiveweb pages, suspending the download and displaying said one media file soas to render the advertisement through the browser to the user.